[PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

[Serge E. Hallyn]

Quoting Eric Paris (eparis at redhat.com):
> On Wed, 2008-10-22 at 21:13 -0700, Andrew G. Morgan wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Serge E. Hallyn wrote:
> > >>> ... except if (!issecure(SECURE_NOROOT) && uid==0) I guess?
> > >>>
> > >>> And then it also might be interesting in the case where
> > >>> (!issecure(SECURE_NOROOT) && uid==0) and pP is not full.
> > >> I guess so, although this seems like a case of being interested in a
> > >> (unusual) non-privileged execve().
> > > 
> > > I'm not sure what you mean - but this can only happen if bits are taken
> > > out of the capability bounding set, right?
> > 
> > Yes, it can happen as you say.
> > 
> > This is a case of an unprivileged uid==0 execution. Since we don't
> > appear to want to audit other non-privileged execve()s, its not clear to
> > me that this one deserves attention.
> 
> So what did you two agree on for when to collect fcaps type information?
> Any time bprm->cap_post_exec_permitted is non-zero?

And (bprm->e_uid!=0 && current->uid!=0 && !issecure(SECURE_NOROOT)) -
otherwise you'll get a hit for every file executed by root.  If you're
ok with that noise, then it's fine with me.  (I assume it can be
filtered out using an audit rule by userspace anyway?)

The inverse case that I suggested is interesting because root was
prevented from running with full capabilities - which could be
indicative of a sendmail-capabilities-bug style of attack.

-serge