* Re: How do I figure out on what file dac_override is attempted? [not found] <19284.52512.295295.185383@gargle.gargle.HOWL> @ 2010-01-19 14:52 ` Stephen Smalley [not found] ` <1263912766.12068.12.camel@moss-pluto.epoch.ncsc.mil> 1 sibling, 0 replies; 11+ messages in thread From: Stephen Smalley @ 2010-01-19 14:52 UTC (permalink / raw) To: Göran Uddeborg; +Cc: linux-audit, selinux 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <1263912766.12068.12.camel@moss-pluto.epoch.ncsc.mil>]
* Re: How do I figure out on what file dac_override is attempted? [not found] ` <1263912766.12068.12.camel@moss-pluto.epoch.ncsc.mil> @ 2010-01-19 15:06 ` Daniel J Walsh [not found] ` <4B55CA8B.3030706@redhat.com> [not found] ` <19286.64383.173222.447312@gargle.gargle.HOWL> 2 siblings, 0 replies; 11+ messages in thread From: Daniel J Walsh @ 2010-01-19 15:06 UTC (permalink / raw) To: Stephen Smalley; +Cc: linux-audit, Göran Uddeborg, selinux 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <4B55CA8B.3030706@redhat.com>]
* Re: How do I figure out on what file dac_override is attempted? [not found] ` <4B55CA8B.3030706@redhat.com> @ 2010-01-19 15:23 ` Stephen Smalley 0 siblings, 0 replies; 11+ messages in thread From: Stephen Smalley @ 2010-01-19 15:23 UTC (permalink / raw) To: Daniel J Walsh; +Cc: linux-audit, Göran Uddeborg, selinux 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <19286.64383.173222.447312@gargle.gargle.HOWL>]
* Re: How do I figure out on what file dac_override is attempted? [not found] ` <19286.64383.173222.447312@gargle.gargle.HOWL> @ 2010-01-20 13:51 ` Stephen Smalley [not found] ` <1263995482.24133.26.camel@moss-pluto.epoch.ncsc.mil> 1 sibling, 0 replies; 11+ messages in thread From: Stephen Smalley @ 2010-01-20 13:51 UTC (permalink / raw) To: Göran Uddeborg; +Cc: linux-audit, selinux 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <1263995482.24133.26.camel@moss-pluto.epoch.ncsc.mil>]
* Re: How do I figure out on what file dac_override is attempted? [not found] ` <1263995482.24133.26.camel@moss-pluto.epoch.ncsc.mil> @ 2010-01-20 15:12 ` Daniel J Walsh 2010-01-20 15:22 ` Stephen Smalley [not found] ` <1264000927.24133.93.camel@moss-pluto.epoch.ncsc.mil> 0 siblings, 2 replies; 11+ messages in thread From: Daniel J Walsh @ 2010-01-20 15:12 UTC (permalink / raw) To: Stephen Smalley; +Cc: linux-audit, Göran Uddeborg, selinux 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How do I figure out on what file dac_override is attempted? 2010-01-20 15:12 ` Daniel J Walsh @ 2010-01-20 15:22 ` Stephen Smalley [not found] ` <1264000927.24133.93.camel@moss-pluto.epoch.ncsc.mil> 1 sibling, 0 replies; 11+ messages in thread From: Stephen Smalley @ 2010-01-20 15:22 UTC (permalink / raw) To: Daniel J Walsh; +Cc: linux-audit, Göran Uddeborg, selinux 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <1264000927.24133.93.camel@moss-pluto.epoch.ncsc.mil>]
[parent not found: <4B572C29.8050600@manicmethod.com>]
* Re: How do I figure out on what file dac_override is attempted? [not found] ` <4B572C29.8050600@manicmethod.com> @ 2010-01-20 19:23 ` Daniel J Walsh [not found] ` <4B57582D.7070904@redhat.com> 1 sibling, 0 replies; 11+ messages in thread From: Daniel J Walsh @ 2010-01-20 19:23 UTC (permalink / raw) To: Joshua Brindle; +Cc: linux-audit, selinux 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <4B57582D.7070904@redhat.com>]
* Re: How do I figure out on what file dac_override is attempted? [not found] ` <4B57582D.7070904@redhat.com> @ 2010-01-20 19:50 ` Stephen Smalley [not found] ` <1264017052.24133.161.camel@moss-pluto.epoch.ncsc.mil> 1 sibling, 0 replies; 11+ messages in thread From: Stephen Smalley @ 2010-01-20 19:50 UTC (permalink / raw) To: Daniel J Walsh; +Cc: linux-audit, selinux, Joshua Brindle 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <1264017052.24133.161.camel@moss-pluto.epoch.ncsc.mil>]
* Re: How do I figure out on what file dac_override is attempted? [not found] ` <1264017052.24133.161.camel@moss-pluto.epoch.ncsc.mil> @ 2010-01-20 20:13 ` Steve Grubb 2010-01-20 20:49 ` Daniel J Walsh [not found] ` <4B576C58.3090801@redhat.com> 2 siblings, 0 replies; 11+ messages in thread From: Steve Grubb @ 2010-01-20 20:13 UTC (permalink / raw) To: linux-audit; +Cc: selinux, Joshua Brindle 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How do I figure out on what file dac_override is attempted? [not found] ` <1264017052.24133.161.camel@moss-pluto.epoch.ncsc.mil> 2010-01-20 20:13 ` Steve Grubb @ 2010-01-20 20:49 ` Daniel J Walsh [not found] ` <4B576C58.3090801@redhat.com> 2 siblings, 0 replies; 11+ messages in thread From: Daniel J Walsh @ 2010-01-20 20:49 UTC (permalink / raw) To: Stephen Smalley; +Cc: linux-audit, selinux, Joshua Brindle 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <4B576C58.3090801@redhat.com>]
* Re: How do I figure out on what file dac_override is attempted? [not found] ` <4B576C58.3090801@redhat.com> @ 2010-01-20 20:57 ` Stephen Smalley 0 siblings, 0 replies; 11+ messages in thread From: Stephen Smalley @ 2010-01-20 20:57 UTC (permalink / raw) To: Daniel J Walsh; +Cc: linux-audit, selinux, Joshua Brindle 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-01-20 20:57 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <19284.52512.295295.185383@gargle.gargle.HOWL>
2010-01-19 14:52 ` How do I figure out on what file dac_override is attempted? Stephen Smalley
[not found] ` <1263912766.12068.12.camel@moss-pluto.epoch.ncsc.mil>
2010-01-19 15:06 ` Daniel J Walsh
[not found] ` <4B55CA8B.3030706@redhat.com>
2010-01-19 15:23 ` Stephen Smalley
[not found] ` <19286.64383.173222.447312@gargle.gargle.HOWL>
2010-01-20 13:51 ` Stephen Smalley
[not found] ` <1263995482.24133.26.camel@moss-pluto.epoch.ncsc.mil>
2010-01-20 15:12 ` Daniel J Walsh
2010-01-20 15:22 ` Stephen Smalley
[not found] ` <1264000927.24133.93.camel@moss-pluto.epoch.ncsc.mil>
[not found] ` <4B572C29.8050600@manicmethod.com>
2010-01-20 19:23 ` Daniel J Walsh
[not found] ` <4B57582D.7070904@redhat.com>
2010-01-20 19:50 ` Stephen Smalley
[not found] ` <1264017052.24133.161.camel@moss-pluto.epoch.ncsc.mil>
2010-01-20 20:13 ` Steve Grubb
2010-01-20 20:49 ` Daniel J Walsh
[not found] ` <4B576C58.3090801@redhat.com>
2010-01-20 20:57 ` Stephen Smalley
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.