Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
From: Mimi Zohar
Date: Thu Feb 14 2013 - 11:54:33 EST
On Thu, 2013-02-14 at 10:03 -0500, Vivek Goyal wrote:
> On Wed, Feb 13, 2013 at 05:27:01PM -0500, Mimi Zohar wrote:
> > > Yep, I got that. Default policy gets overruled when a new policy is
> > > loaded.
> > >
> > > In secureboot mode, somehow above rule needs to take effect by default.
> > > One option would be that kernel can enforce above rule.
> > > (I guess by adding it to both default_list as well as policy list).
> > The default policy is empty, but can be replaced with boot command line
> > options. The existing options are ima_tcb and/ ima_appraise_tcb.
> > Please feel free to define an additional policy.
> I think just defining a new command line option is not sufficient
> for secureboot use case.
> - One can easily remove kernel command line option without breaking
> booting and easily bypass secureboot restrictions.
> - I guess this is one mandated rule by secureboot. There might still
> be a user policy which can co-exist with this rule.
> So to me this is not a new policy. It is just one mandatory rule which
> gets appended to any policy in secureboot mode. Think of it as mandatory
> rule imposed by kernel for any policy user can define. And in secureboot
> mode a user can not get rid of this rule. (Otherwise it breaks user
> space signing and one can bypass secureboot and boot into unsigned
Your rule allows both signed and unsigned files to be executed. Signed
files will just have more capabilities. The ima_appraise_tcb option
requires all files owned by root to be signed, otherwise access is
denied. The two policies simply can not co-exist.
How about defining your single rule as ima_secureboot and making it the
default policy. Only if ima_appraise_tcb is specified on the kernel
command line, will the default policy be replaced. This type of change,
going from a null policy to an ima_secureboot policy, would require
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/