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 linux-cve-announce 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:	Mon, 20 Oct 2008 10:12:01 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	david safford <safford@...son.ibm.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, James Morris <jmorris@...ei.org>,
	Serge Hallyn <serue@...ux.vnet.ibm.com>,
	Mimi Zohar <zohar@...ibm.com>
Subject: Re: [PATCH 2/3] integrity: Linux Integrity Module(LIM)

Quoting david safford (safford@...son.ibm.com):
> On Tue, 2008-10-14 at 09:28 -0400, Christoph Hellwig wrote:
> > >  }
> > >  
> > >  /*
> > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > index 32477e8..349d548 100644
> > > --- 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.
> 
> Sorry, in that thread I thought we were ok, as Serge made the points
> that the bloat would only affect Integrity compiled kernels, that
> no one would press for making Integrity default (not only because of the
> bloat, but even more so because of the performance impact of hashing
> all the files), and that having LIM do MRU would be a big hit, as
> LIM allocates i_integrity for all inodes, and references it on all
> inode_permission, bprm and mmap calls.  

Yes I have to say that in this case, where every inode will have the
field in use, using MRU doesn't seem to make sense.  It's the ideal
case for putting it straight in the inode.

But I hear Mimi is trying it out, so she can report about any
resulting implementation and performance problems.

> If we have to, we have to, but we certainly would prefer not to.
> 
> thanks
> dave
--
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/