Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Arjan van de Ven (arjan@infradead.org):
> On Mon, 2006-04-24 at 08:29 -0500, Serge E. Hallyn wrote:
> > Quoting Arjan van de Ven (arjan@infradead.org):
> > > On Mon, 2006-04-24 at 08:09 -0500, Serge E. Hallyn wrote:
> > > > Quoting Arjan van de Ven (arjan@infradead.org):
> > > > > for all such things in the first place. In fact, we already know that to
> > > > > do auditing, LSM is the wrong thing to do (and that's why audit doesn't
> > > > > use LSM). It's one of those fundamental linux truths: Trying to be
> > > > 
> > > > As I recall it was simply decided that LSM must be "access control
> > > > only", and that was why it wasn't used for audit.
> > > 
> > > no you recall incorrectly.
> > > Audit needs to audit things that didn't work out, like filenames that
> > > don't exist. Audit needs to know what is going to happen before the
> > > entire "is this allowed" chain is going to be followed. SELInux and
> > > other LSM parts are just one part of that chain, and there's zero
> > > guarantee that you get to the LSM part in the chain.....  Now of course
> > 
> > Ah yes.  It needed to be authoritative.  I did recall incorrectly.
> > 
> > I suspect some would argue that you are right that LSM is broken, but
> > only because it wasn't allowed to be authoritative. 
> 
> authoritative isn't enough; think about it. The VFS isn't ever going to
> ask "can I open this file" if the file doesn't exist in the first place;

Current audit doesn't do that either, does it?  It labels the parent
inode, so if /var/spool/mail doesn't exist, and you look up
/var/spool/mail/hallyn, you won't get an audit record.  You'd have to do
that by auditing all open syscalls at the syscall level.

Unless audit has changed that much in the last few months, which is
possible.

-serge