setroubleshoot - kills itself

[Mail Lists]

I was monitoring a remote server (permissive mode) via sealert -b
when setroubleshootd exited with this in /var/log/messages:


Did selinux deny setroubleshootd ?

gene

----------------------------------------------------
Jan 3 13:48:03 web1 setroubleshoot: [program.ERROR] setroubleshoot
generated
AVC, exiting to avoid recursion,
context=system_u:system_r:setroubleshootd_t:s0, AVC
scontext=system_u:system_r:setroubleshootd_t:s0
Jan 3 13:48:03 web1 setroubleshoot: [program.ERROR] audit
event#012node=web1.prv.sapience.com
type=AVC msg=audit(1231008483.779:1387): avc: denied { signull }
for pid=265 9 comm="setroubleshootd"
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=unconf ined_u:unconfined_r:unconfined_t:s0
tclass=process#012#012node=web1.prv.sapience.com type=SYSCALL
msg=audit(1231008483.779:1387): arch=40000003 syscall=37
success=yes exit=0 a0=2079 a1=0 a2=ad454c a3=2079 items=0
ppid=1 pid=2659 auid=4294967295 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
comm="setroubleshootd"
exe=2F7573722F62696E2F707974686F6E2E237072656C696E6B23202864656C6574656429
subj=system_u: system_r:setroubleshootd_t:s0 key=(null)

[Daniel J Walsh]

Post by Mail Lists
I was monitoring a remote server (permissive mode) via sealert -b
Did selinux deny setroubleshootd ?
gene
----------------------------------------------------
Jan 3 13:48:03 web1 setroubleshoot: [program.ERROR] setroubleshoot
generated
AVC, exiting to avoid recursion,
context=system_u:system_r:setroubleshootd_t:s0, AVC
scontext=system_u:system_r:setroubleshootd_t:s0
Jan 3 13:48:03 web1 setroubleshoot: [program.ERROR] audit
event#012node=web1.prv.sapience.com
type=AVC msg=audit(1231008483.779:1387): avc: denied { signull }
for pid=265 9 comm="setroubleshootd"
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=unconf ined_u:unconfined_r:unconfined_t:s0
tclass=process#012#012node=web1.prv.sapience.com type=SYSCALL
msg=audit(1231008483.779:1387): arch=40000003 syscall=37
success=yes exit=0 a0=2079 a1=0 a2=ad454c a3=2079 items=0
ppid=1 pid=2659 auid=4294967295 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
comm="setroubleshootd"
exe=2F7573722F62696E2F707974686F6E2E237072656C696E6B23202864656C6574656429
subj=system_u: system_r:setroubleshootd_t:s0 key=(null)
--
fedora-selinux-list mailing list
fedora-selinux-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

setroubleshoot will die if it finds an AVC about it self to prevent an
infinite loop of avcs.


setroubleshoot can send itself a signull on both Rawhide and F10 with
the latest updates.

[Mail Lists]

Post by Daniel J Walsh
setroubleshoot will die if it finds an AVC about it self to prevent an
infinite loop of avcs.
setroubleshoot can send itself a signull on both Rawhide and F10 with
the latest updates.

What caused it to have a problem ? Is this expected behaviour for
setroubleshootd - or is something amiss that caused it to get the signull ?

Do I need to write a monitor script to keep restarting it ?

[Daniel J Walsh]

Post by Mail Lists

Post by Daniel J Walsh
setroubleshoot will die if it finds an AVC about it self to prevent an
infinite loop of avcs.
setroubleshoot can send itself a signull on both Rawhide and F10 with
the latest updates.

What caused it to have a problem ? Is this expected behaviour for
setroubleshootd - or is something amiss that caused it to get the signull ?
Do I need to write a monitor script to keep restarting it ?
--
fedora-selinux-list mailing list
fedora-selinux-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

No it is probably just a bug in policy.

setroubleshoot executes a lot of code to try to figure out what caused
an AVC, so sometimes a new code path is crossed which we did not write
policy for.