public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: linux-audit@redhat.com
Subject: Re: PATH records show fcaps
Date: Mon, 20 Oct 2008 14:35:18 -0400	[thread overview]
Message-ID: <1224527718.3189.167.camel@paris-laptop> (raw)
In-Reply-To: <20081020181337.GA776@us.ibm.com>

On Mon, 2008-10-20 at 13:13 -0500, Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@redhat.com):
> > On Mon, 2008-10-20 at 11:33 -0500, Serge E. Hallyn wrote:
> > > 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)
> > > 
> > > This part above is the credentials of the running task, right?  Will it
> > > output your process inheritable set if nonempty?
> > > 
> > > (I would think you should be able to test this by doing
> > > 
> > > 	capsh --inh=cap_sys_admin /bin/sh
> > > 	/bin/foo
> > > 
> > > and look for /bin/foo's record)
> > > 
> > > thanks,
> > > -serge
> > 
> > For this (patch 2) I'm adding information so you can tell a process
> > escalated it privs with fcaps.  This really means you have to audit
> > EXECVE (since this is when fcaps are applied)
> > 
> > setcap "cap_net_admin+pei" /bin/bash
> > setcap "cap_net_raw+pei" /bin/ping
> > 
> > auditctl -a exit,always -S execve -F path=/bin/ping
> > 
> > type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=1 name=(null) inode=507963 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 
> > type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=0 name=/bin/ping inode=49227 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_fP=0000000000002000 cap_fE=1 cap_fVer=2
> > type=CWD msg=audit(10/20/2008 13:27:55.318:218) :  cwd=/home/test 
> > type=UNKNOWN[1321] msg=audit(10/20/2008 13:27:55.318:218) :  cap_fP=0000000000002000 cap_fI=0000000000000000 cap_fE=1 cap_pP=0000000000001000 cap_pI=0000000000000000 cap_pE=0000000000001000 cap_bprmE=0000000000002000 
> 
> This looks wrong - you say above that you set cap_net_raw in fI for
> ping, but this shows fI as empty?

/*
 * pP' = (X & fP) | (pI & fI)
 */

Not going to disagree that is weird but fcaps aren't inheritable from my
looking at the code.  Both fP and fI get collapsed by the above equation
(X is the per process bounding set) into bprm->cap_post_exec_permitted.
Then at the end of execve, cap_bprm_apply_creds(), you get:

bprm->cap_post_exec_permitted = cap_intersect(bprm->cap_post_exec_permitted,
                                              current->cap_permitted);
[snip]
current->cap_permitted = bprm->cap_post_exec_permitted;
if (bprm->cap_effective)
        current->cap_effective = bprm->cap_post_exec_permitted;

fcaps at least from my reading are not inheritable and basically it
looks to me like the only thing fI really means is that they can get
pushed into pP (and pE) if they intersect with pI.

/me doesn't really mind having fI not be inheritable.  Although I'm not
sure why we need that weird twist on the meaning fI....

-Eric

  reply	other threads:[~2008-10-20 18:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-18 15:23 PATH records show fcaps Eric Paris
2008-10-20 10:56 ` Steve Grubb
2008-10-20 13:32   ` Eric Paris
2008-10-20 16:31 ` Serge E. Hallyn
2008-10-20 16:55   ` Eric Paris
2008-10-20 17:13     ` Serge E. Hallyn
2008-10-20 22:52     ` Steve Grubb
2008-10-20 23:00       ` Eric Paris
2008-10-21  2:21         ` Steve Grubb
2008-10-20 16:33 ` Serge E. Hallyn
2008-10-20 17:55   ` Eric Paris
2008-10-20 18:13     ` Serge E. Hallyn
2008-10-20 18:35       ` Eric Paris [this message]
2008-10-20 19:13         ` Serge E. Hallyn
2008-10-20 19:49           ` Eric Paris
2008-10-20 20:01             ` Serge E. Hallyn

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=1224527718.3189.167.camel@paris-laptop \
    --to=eparis@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox