Re: PATH records show fcaps
On Mon, 2008-10-20 at 13:13 -0500, Serge E. Hallyn wrote:
Quoting Eric Paris (eparis(a)redhat.com):
> On Mon, 2008-10-20 at 11:33 -0500, Serge E. Hallyn wrote:
> > Quoting Eric Paris (eparis(a)redhat.com):
> > > type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59
success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1
comm="ping" exe="/bin/ping"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> >
> > This part above is the credentials of the running task, right? Will it
> > output your process inheritable set if nonempty?
> >
> > (I would think you should be able to test this by doing
> >
> > capsh --inh=cap_sys_admin /bin/sh
> > /bin/foo
> >
> > and look for /bin/foo's record)
> >
> > thanks,
> > -serge
>
> For this (patch 2) I'm adding information so you can tell a process
> escalated it privs with fcaps. This really means you have to audit
> EXECVE (since this is when fcaps are applied)
>
> setcap "cap_net_admin+pei" /bin/bash
> setcap "cap_net_raw+pei" /bin/ping
>
> auditctl -a exit,always -S execve -F path=/bin/ping
>
> type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=1 name=(null) inode=507963
dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0
> type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=0 name=/bin/ping inode=49227
dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:ping_exec_t:s0 cap_fP=0000000000002000 cap_fE=1 cap_fVer=2
> type=CWD msg=audit(10/20/2008 13:27:55.318:218) : cwd=/home/test
> type=UNKNOWN[1321] msg=audit(10/20/2008 13:27:55.318:218) : cap_fP=0000000000002000
cap_fI=0000000000000000 cap_fE=1 cap_pP=0000000000001000 cap_pI=0000000000000000
cap_pE=0000000000001000 cap_bprmE=0000000000002000
This looks wrong - you say above that you set cap_net_raw in fI for
ping, but this shows fI as empty?
/*
* pP' = (X & fP) | (pI & fI)
*/
Not going to disagree that is weird but fcaps aren't inheritable from my
looking at the code. Both fP and fI get collapsed by the above equation
(X is the per process bounding set) into bprm->cap_post_exec_permitted.
Then at the end of execve, cap_bprm_apply_creds(), you get:
bprm->cap_post_exec_permitted = cap_intersect(bprm->cap_post_exec_permitted,
current->cap_permitted);
[snip]
current->cap_permitted = bprm->cap_post_exec_permitted;
if (bprm->cap_effective)
current->cap_effective = bprm->cap_post_exec_permitted;
fcaps at least from my reading are not inheritable and basically it
looks to me like the only thing fI really means is that they can get
pushed into pP (and pE) if they intersect with pI.
/me doesn't really mind having fI not be inheritable. Although I'm not
sure why we need that weird twist on the meaning fI....
-Eric