Quoting Eric Paris ([EMAIL PROTECTED]):
> 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="127.0.0.1"
> 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....
<background>
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.
</background>
<summary>
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)?
</summary>
-serge
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
