From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: PATH records show fcaps Date: Mon, 20 Oct 2008 11:31:05 -0500 Message-ID: <20081020163104.GA21901@us.ibm.com> References: <1224343392.3189.74.camel@paris-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1224343392.3189.74.camel@paris-laptop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Eric Paris Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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.... 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. 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)? -serge