All of lore.kernel.org
 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 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.