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

Re: 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

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

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

[Daniel J Walsh]

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?

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: 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

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

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

[Stephen Smalley]

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?

-- 
Stephen Smalley
National Security Agency

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

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

[Daniel J Walsh]

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?

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

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

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

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

[Daniel J Walsh]

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

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: 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

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

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

[Steve Grubb]

On Wednesday 20 January 2010 02:50:52 pm Stephen Smalley wrote:
> > 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.

I had suggested to Dan to use a file watch so as not to impact performance as 
much if the system is a busy one, but I had suggested a file that should never 
be written to like /etc/service, /etc/shells, or /etc/protocols. The file is 
matched by hash rather than looping through the syscall rules which does make 
things run faster.

> 2) I see a type=PATH record rather than type=AVC_PATH, e.g.:
> 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.

That would be duplication of audit records. PATH should be emitted whenever 
you want the object of the syscall. It appears that AVC_PATH has been 
deprecated.

-Steve

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

[Daniel J Walsh]

On 01/20/2010 02:50 PM, Stephen Smalley wrote:
> 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 

Why does path begin with a ./capable_file/temp_file?

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

[Stephen Smalley]

On Wed, 2010-01-20 at 15:49 -0500, Daniel J Walsh wrote:
> On 01/20/2010 02:50 PM, Stephen Smalley wrote:
> > 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 
> 
> Why does path begin with a ./capable_file/temp_file?

Because the audit system is collecting the pathname string that was
passed to the system call, and that pathname was a relative path.  But
note the CWD record which enables you to deduce the absolute path.

-- 
Stephen Smalley
National Security Agency