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

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)
> 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

  parent reply	other threads:[~2008-10-20 16:31 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 [this message]
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
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=20081020163104.GA21901@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=eparis@redhat.com \
    --cc=linux-audit@redhat.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