auditing file based capabilities

auditing file based capabilities

[Steve Grubb]

Hi,

With file based capabilities in recent kernels, I think we need to add those 
to the path records. An example PATH record:

node=127.0.0.1 type=PATH msg=audit(1223893548.459:459): item=1 
name="/etc/resolv.conf" inode=20774937 dev=08:08 mode=0100644 ouid=0 ogid=0 
rdev=00:00 obj=system_u:object_r:net_conf_t:s0

If executing the file leads to extra capabilities, I think we need to record 
that. If we add it, I'd like to see it recorded like render_cap_t does for 
the proc filesystem. In order to conserve disk space, should we make the 
field optional so that it doesn't appear in the record unless there are file 
based capabilities?

Thanks,
-Steve

Re: auditing file based capabilities

[Serge E. Hallyn]

Quoting Steve Grubb (sgrubb@redhat.com):
> Hi,
> 
> With file based capabilities in recent kernels, I think we need to add those 
> to the path records. An example PATH record:

That's a great idea (and would get me to use audit :).

> node=127.0.0.1 type=PATH msg=audit(1223893548.459:459): item=1 
> name="/etc/resolv.conf" inode=20774937 dev=08:08 mode=0100644 ouid=0 ogid=0 
> rdev=00:00 obj=system_u:object_r:net_conf_t:s0
> 
> If executing the file leads to extra capabilities, I think we need to record 
> that. If we add it, I'd like to see it recorded like render_cap_t does for 
> the proc filesystem.

Agreed.  Then userspace tools can print out full capability names.

> In order to conserve disk space, should we make the 
> field optional so that it doesn't appear in the record unless there are file 
> based capabilities?

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?

-serge

Re: auditing file based capabilities

[Steve Grubb]

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?

-Steve

Re: auditing file based capabilities

[Serge E. Hallyn]

Quoting Steve Grubb (sgrubb@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).

-serge

Re: auditing file based capabilities

[Steve Grubb]

On Monday 13 October 2008 11:42:31 Serge E. Hallyn wrote:
> Quoting Steve Grubb (sgrubb@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

Re: auditing file based capabilities

[LC Bruzenak]

On Mon, 2008-10-13 at 09:04 -0500, 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?
> 
> -serge

I think it already happens right (?):

node=hugo type=USER_CMD msg=audit(10/13/2008 10:13:33.616:27271) : user
pid=5202 uid=root auid=lenny subj=user_u:user_r:user_t:s0-s15:c0.c1023
msg='cwd=/home/lenny/src2/OED/test/audit cmd=/usr/sbin/setcap
cap_audit_write+pe audit-test (terminal=pts/4 res=success)' 
----
node=hugo type=PATH msg=audit(10/13/2008 10:13:33.617:27272) : item=0
name=audit-test inode=820271 dev=fd:00 mode=file,755 ouid=lenny
ogid=lenny rdev=00:00 obj=user_u:object_r:user_home_t:s0 
node=hugo type=CWD msg=audit(10/13/2008 10:13:33.617:27272) :
cwd=/home/lenny/src2/OED/test/audit 
node=hugo type=SYSCALL msg=audit(10/13/2008 10:13:33.617:27272) :
arch=x86_64 syscall=setxattr success=yes exit=0 a0=7fff68c57a2a
a1=35a1402b44 a2=7fff68c55b20 a3=14 items=1 ppid=11723 pid=5202
auid=lenny uid=root gid=root euid=root suid=root fsuid=root egid=root
sgid=root fsgid=root tty=pts4 ses=215 comm=setcap exe=/usr/sbin/setcap
subj=user_u:user_r:user_t:s0-s15:c0.c1023 key=(null) 
node=hugo type=AVC msg=audit(10/13/2008 10:13:33.617:27272) : avc:
denied  { setfcap } for  pid=5202 comm=setcap
capability=scontext=user_u:user_r:user_t:s0-s15:c0.c1023
tcontext=user_u:user_r:user_t:s0-s15:c0.c1023 tclass=capability 


LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com