6:15 a.m.
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
9:04 a.m.
Quoting Steve Grubb (sgrubb(a)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
10:21 a.m.
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
10:42 a.m.
Quoting Steve Grubb (sgrubb(a)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
11:53 a.m.
On Monday 13 October 2008 11:42:31 Serge E. Hallyn wrote:
Quoting Steve Grubb (sgrubb(a)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
10:25 a.m.
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(a)magitekltd.com
5914
days inactive
5914
days old
linux-audit@lists.linux-audit.osci.io
5 comments
3 participants
participants (3)
-
LC Bruzenak -
Serge E. Hallyn -
Steve Grubb