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

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency