From: Steve Grubb <sgrubb@redhat.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Linux Audit <linux-audit@redhat.com>
Subject: Re: auditing file based capabilities
Date: Mon, 13 Oct 2008 12:53:12 -0400 [thread overview]
Message-ID: <200810131253.12246.sgrubb@redhat.com> (raw)
In-Reply-To: <20081013154231.GA9175@us.ibm.com>
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
next prev parent reply other threads:[~2008-10-13 16:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-13 11:15 auditing file based capabilities Steve Grubb
2008-10-13 14:04 ` Serge E. Hallyn
2008-10-13 15:21 ` Steve Grubb
2008-10-13 15:42 ` Serge E. Hallyn
2008-10-13 16:53 ` Steve Grubb [this message]
2008-10-13 15:25 ` LC Bruzenak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200810131253.12246.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=serue@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.