linux-kernel - Re: [PATCH v2 1/4] ima: added policy support for 'security.ima' type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Jan 2013 13:41:44 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	linux-security-module@...r.kernel.org,
	Dmitry Kasatkin <dmitry.kasatkin@...el.com>,
	James Morris <jmorris@...ei.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/4] ima: added policy support for 'security.ima' type

On Wed, Jan 30, 2013 at 05:42:39PM -0500, Mimi Zohar wrote:
> On Wed, 2013-01-30 at 16:53 -0500, Vivek Goyal wrote:
> > On Tue, Jan 22, 2013 at 05:07:31PM -0500, Mimi Zohar wrote:
> > 
> > [..]
> > >  /* iint cache flags */
> > > +#define IMA_ACTION_FLAGS	0xff00
> > >  #define IMA_DIGSIG		0x0100
> > > +#define IMA_DIGSIG_REQUIRED	0x0200
> > 
> > Hi Mimi,
> > 
> > IMA_DIGSIG_REQUIRED state does not really have to be stored in iint I guess.
> > This is needed only if we go on to appraise and then we want to make
> > sure digital signatures are present. Once appraisal is done, IMG_DIGSIG
> > will be set and saved in iint->flags but looks like we don't require
> > IMA_DIGSIG_REQUIRED to be saved.
> > 
> > If yes, will it make sense to not save it in iint. There are still 8
> > bits left unused. We can mark these 8 bits for temporary flags like
> > IMA_DIGSIG_REQUIRED. If that works, I can use same space for defining
> > additional temporary flags like IMA_DIGSIG_SIGNED_ONLY to handle the
> > case of appraise_type=imasig,signed_only. That flag also does not have
> > to be persistent in iint.
> 
> Interesting idea.  My only concern would be that we're not leaving room
> for additional hooks (eg. firmware).

Ok. May be we can employ another 32bit variable and put both of them in
a structure to expand it, when firmware hooks come along.

Or I can do that right now, if you like it that way.

I need to move out non-persistent flags from iint flags, otherwise it
can happen that conflicting flag might be set from different hooks.

For example, say hypothetically there are too hooks.

appraise fowner=0 func=mmap appraise_type=imasig
appraise fowner=0 func=BPRM_CHECK appraise_type=imasig_signed_only

Now this will lead to setting of both IMA_DISGIG_REQUIRED and
IMA_DIGSIG_SIGNED_ONLY in iint->flags and that does not mean much in
the context of iint.

So by keeping them temporary, these flags become kind of hook specific
and then two appraise hook don't conflict with each other.

Thanks
Vivek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/