All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.