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:54 -0500, Serge E. Hallyn wrote:
> > 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?  
> 
> As far as I know, it actually does. (assuming you configure it do audit
> such events obviously)

If the parent directory exists, yes.  LSM could do that too.  If the
parent directory does not exist, then you cannot create an audit rule.
I.e. if /var/spool/mail does not exist, you cannot watch
/var/spool/mail/hallyn.  If you have an active rule for
/var/spool/mail/hallyn and you rm -rf /var/spool/mail, the audit rule is
implicitly deleted.  If you then recreate /var/spool/mail, and touch
/var/spool/mail/hallyn, you get no audit entries.

> > 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.
> 
> That's a wrong assumption. There is one level below the syscall level as

What is the wrong assumption?  That it has to be "at the syscall level"?
Ok, it has to be done at syscall entry or exit, if you prefer.  Using
syscall auditing, catching all fs events, and grepping with ausearch.

> well in Linux, and that is where you need to audit for this, and afaik
> audit actually does that.

Nope.

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