[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PATH records show fcaps

Quoting Eric Paris (eparis 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)
> type=EXECVE msg=audit(1224342849.465:43): argc=2 a0="ping" a1="" 
> type=CWD msg=audit(1224342849.465:43):  cwd="/root"
> type=PATH msg=audit(1224342849.465:43): item=0 name="/bin/ping" inode=49227 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_permitted=0000000000002000 cap_inheritable=0000000000000000
> type=PATH msg=audit(1224342849.465:43): item=1 name=(null) inode=507963 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
> This good?  If either cap_permitted or cap_inheritable have anything set
> I show them both.  In the above example would you rather I only showed
> cap_permitted and dropped cap_inheritable?  Did I see correctly that

I think dropping the empty one is fine.

Steve's suggestion of cap_prm and cap_inh are good for being shorter and
matching proc output.  But OTOH it's a bit confusing as at first I
thought these were the task's values.  Would it be too terse to just
use fP and fI?

> it's possible to set a cap_effective on a file?  Does it do anything?  I
> didn't see that getting used or read in the kernel, so I didn't put any
> way to display it in kernel....

The idea is that putting bits in fE will cause them to be in pE' after
exec.  But the way it is interpreted is as a boolean, so either
pE' is empty or it is set to pP'.  So if you do

	setcap cap_dac_override=pe /bin/foo

then executing /bin/foo will land cap_dac_override in your effective
and permitted sets.  If you do

	setcap cap_dac_override=pe /bin/foo

then it  will land only in your permitted set.



I thought the kernel looked at the actual contents of fE, but now I see
that instead setcap sets a VFS_CAP_FLAGS_EFFECTIVE flag in the
capability xattr magic value.  So the effective value appears to be
unused.  But the VFS_CAP_FLAGS_EFFECTIVE (aka 'legacy bit'), if set, is
obviously very important, and should be printed out, at least if it is
set.  Perhaps just 'cap_legacy=true' if it's set?

And actually the capability revision # might be useful too.  Perhaps
output that only if it doesn't match kernel default (VFS_CAP_REVISION)?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]