How do I figure out on what file dac_override is attempted?

[Stephen Smalley]

On Wed, 2010-01-20 at 14:23 -0500, Daniel J Walsh wrote:
> On 01/20/2010 11:15 AM, Joshua Brindle wrote:
> > Stephen Smalley wrote:
> >> On Wed, 2010-01-20 at 10:12 -0500, Daniel J Walsh wrote:
> >>> On 01/20/2010 08:51 AM, Stephen Smalley wrote:
> >>>> On Wed, 2010-01-20 at 13:47 +0100, Göran Uddeborg wrote:
> >>>>> Stephen Smalley:
> >>>>>> To get object information, you need to enable
> >>>>>> syscall auditing, and add a trivial syscall filter to turn on
> >>>>>> pathname
> >>>>>> collection by the audit subsystem.
> >>>>> Thanks for that tip (all of you who gave it)!  I now know it is
> >>>>> /dev/fb that plymouthd can't access.  The audit record also told me it
> >>>>> was owned by a regular user and mode rw-------.  So now it makes
> >>>>> sense.  A root process would need dac_override to open that file.
> >>>> That tip really ought to get captured in the Fedora SELinux FAQ or
> >>>> Guide.  Dan?
> >>>>
> >>> You mean turning on full auditing if you have a suspicious DAC_OVERRIDE?
> >>
> >> More generally, if you want full pathname information for an AVC denial
> >> and you aren't getting it in the AVC message, you can get it by adding a
> >> trivial audit syscall filter and re-trying the operation, where adding a
> >> trivial audit syscall filter can be done by any of the three examples
> >> given by Steve Grubb, Eric, or myself - take your pick.  It can be done
> >> temporarily just by running auditctl or on every boot by adding the
> >> entry to /etc/audit/audit.rules.
> >>
> > 
> > Can we add it to selinuxproject.org instead (or in addition to, I guess?)
> 
> Here is my blog on it.
> 
> http://danwalsh.livejournal.com/34903.html

1) Your watch will actually trigger some audit messages since that file
does get written sometimes, vs. using Eric or Steve Grubb's suggestion
which should never fire.

2) I see a type=PATH record rather than type=AVC_PATH, e.g.:
type=PATH msg=audit(01/20/2010 14:43:20.785:41253) : item=0 name=./capable_file/temp_file inode=841249 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:test_file_t:s0 
type=CWD msg=audit(01/20/2010 14:43:20.785:41253) :  cwd=/home/sds/selinux-testsuite/tests 
type=SYSCALL msg=audit(01/20/2010 14:43:20.785:41253) : arch=x86_64 syscall=fchownat success=no exit=-1(Operation not permitted) a0=ffffffffffffff9c a1=1687310 a2=2 a3=ffffffff items=1 ppid=5167 pid=5182 auid=sds uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1110 comm=chown exe=/bin/chown subj=unconfined_u:unconfined_r:test_nofcap_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(01/20/2010 14:43:20.785:41253) : avc:  denied  { chown } for  pid=5182 comm=chown capability=chown scontext=unconfined_u:unconfined_r:test_nofcap_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:test_nofcap_t:s0-s0:c0.c1023 tclass=capability 

As I recall, AVC_PATH was for the case where we could directly generate
the pathname during AVC audit (i.e. the hook had the vfsmount and dentry
available to it), whereas PATH is when syscall audit collected the
pathname on entry.

-- 
Stephen Smalley
National Security Agency