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

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?