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

[Stephen Smalley]

On Tue, 2010-01-19 at 10:06 -0500, Daniel J Walsh wrote:
> On 01/19/2010 09:52 AM, Stephen Smalley wrote:
> > On Mon, 2010-01-18 at 22:05 +0100, Göran Uddeborg wrote:
> >> Here is another strange AVC I'm trying to understand.
> >>
> >> SETroubleshoot on one of my machines is telling me that
> >>
> >>   SELinux is preventing plymouthd (plymouthd_t) "dac_override" plymouthd_t.
> >>
> >> The full message is attached.
> >>
> >> If I have understood this correctly, this means that plymouthd was
> >> trying to read a file as root.  But the regular permissions bits of
> >> the file would not allow that.  (Right?)
> >>
> >> I assume there is some file with wrong permission bits, which causes
> >> this to happen.  But I can't find any indication WHAT file it was.
> >> Looking at the message, it seems to me it was trying a dac_override on
> >> itself.
> >>
> >> Is there a way to know what file was involved?
> > 
> > The capability checks in Linux do not pass the object to the security
> > module, so SELinux only knows about the current task and the particular
> > capability requested.  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.  Then re-try the operation that
> > generated the denial.
> > 
> > auditctl -s
> > will show the current status of the audit system.
> > 
> > auditctl -a exit,always -S chroot
> > is an example syscall filter.
> > 
> > The filter doesn't need to have anything to do with your failing
> > operation - it just turns on the machinery that will cause pathname
> > collection so that when the AVC is generated, you will also get a
> > SYSCALL record with the pathname info.
> > 
> So there is no easy way in the kernel to get this information into the AVC without taking the overhead hit of 
> full path auditing.
> 
> > The capability checks in Linux do not pass the object to the security
> > module, so SELinux only knows about the current task and the particular
> > capability requested.
> 
> Would this be insanity to ask that the object be passed to the capability check?

Insanity, no. But it would require a kernel patch to pass object
information to capable() calls, and a sufficiently flexible approach to
support any kind of object relevant to any capable() call.  Or replacing
all of the capable() calls with LSM security hooks.  That was considered
when LSM was created, but with > 1000 calls to capable() scattered
throughout the Linux kernel, it wasn't viewed as especially practical.

A more targeted approach of replacing a few select capable() calls with
more specialized interfaces, e.g. capable_inode(), would be feasible.

-- 
Stephen Smalley
National Security Agency