auditing file based capabilities

[Steve Grubb]

On Monday 13 October 2008 11:42:31 Serge E. Hallyn wrote:
> Quoting Steve Grubb (sgrubb at redhat.com):
> > On Monday 13 October 2008 10:04:27 Serge E. Hallyn wrote:
> > > Except I think setcap should also be audited, so that if a task
> > > receives some inheritable capabilities, you can tell from the logs when
> > > that happened and which executable did it.
> > >
> > > Do you already have a patch for this?
> >
> > Would an audit rule for setxattrs cover the setting?
>
> Sorry, I meant capset :)
>
> A task changing its capability sets.  Particularly if it adds to pI (as
> login/pam_cap will likely do).

We can audit the capset syscall. But we do not have a capabilities auxiliary 
record that spells out exactly what changed. This is what you get:

node=127.0.0.1 type=SYSCALL msg=audit(10/13/2008 12:47:02.969:18058) : 
arch=x86_64 syscall=capset success=yes exit=0 a0=7f8d539a9874 a1=7f8d539a987c 
a2=e a3=7fff5a457ba0 items=0 ppid=9102 pid=9103 auid=sgrubb uid=root gid=root 
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 
comm=mcstransd exe=/sbin/mcstransd 
subj=unconfined_u:system_r:setrans_t:s0-s0:c0.c1023 key=capability 

As best as I can tell, the a0 and a1 are pointers to structures with that info 
and we have no access to it. I think that we should have an aux record for 
the 3 sets of capabilities being passed in.

-Steve