linux-kernel - Re: [PATCH 2/3] integrity: Linux Integrity Module(LIM)

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 PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 31 Oct 2008 15:48:34 -0400
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, James Morris <jmorris@...ei.org>,
	David Safford <safford@...son.ibm.com>,
	Serge Hallyn <serue@...ux.vnet.ibm.com>,
	Mimi Zohar <zohar@...ibm.com>
Subject: Re: [PATCH 2/3] integrity: Linux Integrity Module(LIM)

On Fri, 2008-10-31 at 09:51 -0700, Dave Hansen wrote: 
> On Tue, 2008-10-14 at 09:28 -0400, Christoph Hellwig wrote:
> > > --- a/include/linux/fs.h
> > > +++ b/include/linux/fs.h
> > > @@ -683,6 +683,9 @@ struct inode {
> > >  #ifdef CONFIG_SECURITY
> > >       void                    *i_security;
> > >  #endif
> > > +#ifdef CONFIG_INTEGRITY
> > > +     void                    *i_integrity;
> > > +#endif
> > 
> > Sorry, but as said before bloating the inode for this is not an option.
> > Please use something like the MRU approach I suggested in the last
> > review round.

I am working on using a radix tree to store the i_integrity information,
as Christoph suggested. Initially the measurements were awful, but after
fixing the locking and removing an unnecessary sychronize_rcu, I'm not
seeing a major performance hit. 

> Why don't we just have a 'void *i_lots_of_bloat field', and let the
> security folks stick whatever they want in it?  They can trade their
> i_security space for a new one.  I know we want to conceptually separate
> security from integrity, so let's separate it:
> 
> struct i_bloat_inodes {
> #ifdef CONFIG_SECURITY
> 	void                    *i_security;
> #endif
> #ifdef CONFIG_INTEGRITY
> 	void                    *i_integrity;
> #endif
> };

I'm not sure that the LSM people would be too happy.  If using the radix
tree does not pan out, then we will have to look into this option.

> By the way, if there's no TPM hardware, why would I want i_integrity
> anyway?

> -- Dave

The integrity framework is for collecting, appraising, and storing
integrity information.  Integrity measurements today are mainly file
measurements, but the framework allows for other types of integrity
measurements. Some types of integrity measurements, might only require
collecting and appraising, but not storing, so a TPM would not be
required.

Mimi

--
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/