Bug 427721 - setroubleshoot dies
setroubleshoot dies
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-06 22:36 EST by Ralf Corsepius
Modified: 2009-12-18 01:02 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:02:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of ausearch -m AVC near to the time of the incident reported above (6.51 KB, application/octet-stream)
2008-01-07 11:31 EST, Ralf Corsepius
no flags Details
setroubleshoot errors from start to crash (5.63 KB, application/octet-stream)
2008-02-26 01:54 EST, Johan Cwiklinski
no flags Details

  None (edit)
Description Ralf Corsepius 2008-01-06 22:36:53 EST
Description of problem:
setroubleshoot dies.


Symptoms:
After bootup and first gdm/runlevel-5-login, setroubleshoot initially appears to
work, but seems to die upon first SELinux-alert.

Afterwards, the situation is as follows:
# /sbin/chkconfig --list setroubleshoot 
setroubleshoot  0:off   1:off   2:off   3:on    4:on    5:on    6:off
# /sbin/service setroubleshoot status
setroubleshootd dead but pid file exists


Manually relaunching setroubleshoot brings up setroubleshootd again:
# /sbin/service setroubleshoot restart
Stopping setroubleshootd:                                  [FAILED]
Starting setroubleshootd:                                  [  OK  ]

Afterwards, when an SELinux-alert occurs, the "SETroubleShoot star" appears on
the desktop. When clicking onto it, the setroubleshoot-browser pops up, but
appears empty and complains "Connection refused".

Afterwards, the setroubleshoot service appears dead again:
# /sbin/service setroubleshoot status
setroubleshootd dead but pid file exists

How reproducible:
I can reproduce this on one x86_64/FC8 system but am not able to reproduce it on
my other FC8 machines (all i386-FC8).

Steps to Reproduce:
Cf. above.

Version:
# rpm -qa 'setrouble*'
setroubleshoot-server-1.10.7-1.fc8
setroubleshoot-plugins-1.10.4-1.fc8
setroubleshoot-1.10.7-1.fc8


Actual results:
setroubleshoot is not working at all.

Expected results:
function.

Additional info:
In /var/log/messages, I am seeing this next to the point in time of a
setroubleshoot breakdown:

Jan  7 03:57:32 beck setroubleshoot: [rpc.ERROR] attempt to open server
connection failed: Connection refused
Jan  7 04:14:17 beck setroubleshoot: #012    SELinux is preventing
/usr/sbin/rpc.mountd (nfsd_t) "ioctl" to /dev/mapper/control
(lvm_control_t).#012     For complete SELinux messages. run sealert -l
6100985c-f0f6-4b52-87b1-d9ac8f3bee6a
Jan  7 04:14:17 beck setroubleshoot: #012    SELinux is preventing the nfs
daemon from serving r/o local files to remote clients.#012     For complete
SELinux messages. run sealert -l dcb096e3-385c-41ae-bcb9-c9543de8eb03
Jan  7 04:14:19 beck setroubleshoot: [program.ERROR] Can not handle AVC'S
related to dispatcher. exiting#012setroubleshoot
context=unconfined_u:system_r:setroubleshootd_t:s0, AVC
scontext=unconfined_u:system_r:setroubleshootd_t:s0
Comment 1 Eric Paris 2008-01-07 11:02:23 EST
can you attach the output of ausearch -m AVC (possibly with -ts recent if it is
too long)
Comment 2 Ralf Corsepius 2008-01-07 11:31:59 EST
Created attachment 290977 [details]
output of ausearch -m AVC near to the time of the incident reported above
Comment 3 John Dennis 2008-01-07 11:41:05 EST
This is due to setroubleshoot generating it's own AVC. In theory this should
never happen and is probably due to a policy bug. To prevent infinite recursion
setroubleshootd exits if it ever sees an AVC denial related to it's own operation.

There were policy fixes related to setroubleshoot, are your selinux policies up
to date? If not please they upgrading to the latest policies. If the problem
goes away please update this bugzilla with that information and close it. If the
problem persists then please provide the full rpm version of your selinux
policies (including the arch).
Comment 4 Ralf Corsepius 2008-01-07 12:20:22 EST
(In reply to comment #3)
> This is due to setroubleshoot generating it's own AVC. In theory this should
> never happen and is probably due to a policy bug. To prevent infinite recursion
> setroubleshootd exits if it ever sees an AVC denial related to it's own operation.
Hmm, suicide as fallback? ;)

> There were policy fixes related to setroubleshoot, are your selinux policies up
> to date?
I think so. This particular machine is ca. 4 weeks old and had received FC8 from
scratch (Unlike my other machines which had been updated to FC8 from FC < 8),
ca. Dec 10 2007. 

Frankly speaking, SELinux has never worked satisfactory on it.

# rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' '*selinux*'
selinux-policy-targeted-3.0.8-72.fc8.noarch
libselinux-devel-2.0.43-1.fc8.x86_64
selinux-policy-3.0.8-72.fc8.noarch
libselinux-2.0.43-1.fc8.i386
libselinux-2.0.43-1.fc8.x86_64
libselinux-python-2.0.43-1.fc8.x86_64
selinux-policy-devel-3.0.8-72.fc8.noarch

> If not please they upgrading to the latest policies. If the problem
> goes away please update this bugzilla with that information and close it. If the
> problem persists then please provide the full rpm version of your selinux
> policies (including the arch).
c.f. above.

# cat /etc/selinux/config | grep '^SE'
SELINUX=permissive
SELINUXTYPE=targeted 
SETLOCALDEFS=0 

So what's left to try for me? .autorelabel?
Comment 5 John Dennis 2008-01-07 18:11:02 EST
One more thought... It's not normal for setroubleshoot to generate an AVC. As
with many other AVC denials the root cause might be a simple case of a mislabled
file system. You might consider relabling the file system on the system you're
having problems with. The fact this is the only system you're having problems
with may support the supposition the problem arises from incorrect labeling.

To relabel, as root

touch /.autorelabel

then reboot
Comment 6 Ralf Corsepius 2008-01-08 02:11:37 EST
.autorelabel didn't really help.

setroubleshoot initially seems to have worked, but now (ca. 30 mins after
reboot), it's dead again.

Comment 7 Daniel Walsh 2008-01-08 06:30:50 EST
You can allow this for now by executing 

# audit2allow -M mypol -i /var/log/audit/audit.log 
# semodule -i mypol.pp

Fixed in selinux-policy-3.0.8-74.fc8

The only one I did not allow was the reading of the .rpmmacros file labeled
home_root_t.  Since I think this is a mislabeled file.
Comment 8 Ralf Corsepius 2008-01-08 08:28:54 EST
Now things are getting really bizarre:

# audit2allow -M mypol -i /var/log/audit/audit.log
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i mypol.pp

# semodule -i mypol.pp
libsepol.check_assertion_helper: neverallow violated by allow nfsd_t
fixed_disk_device_t:blk_file { read }; Cannot allocate memory.
libsemanage.semanage_expand_sandbox: Expand module failed Cannot allocate memory.
semodule:  Failed!

[This is with *-73.fc8 from testing (Which also doesn't help)]
Comment 9 John Dennis 2008-01-08 10:36:53 EST
Ah ha... The old .rpmmacro problem. I knew this sounded familar, it was first
reported by Tom London in bug 222498. When this first came up I recall looking
at the source code to rpm (ugh) and I seem to recall it unconditionally searched
for and read .rpmmacros even if it was not required for the operation, in this
case a query. BTW setroubleshoot uses RPM to find out which RPM an offending
file belongs to.

The likelyhood RPM will fix it's bogus behavior is pretty low. I thought I might
have filed a bugzilla against RPM, but apparently I didn't, or at least I can't
find it now.

I thought we had fixed this long ago by permitting access to ~/.rpmmacros in the
policy, am I mistaken?
Comment 10 Daniel Walsh 2008-01-11 15:02:51 EST
You should be able to download selinux-policy-3.0.8-74.fc8 from fedora-testing

Or you can grab it from

http://people.fedoraproject.org/~dwalsh/SELinux/F8
Comment 11 Daniel Walsh 2008-01-11 15:03:56 EST
BTW If you want to build the policy module you should only grab the
setroubleshoot avc's

# grep setroubleshoot /var/log/audit/audit.log  | audit2allow -M mypol -i 
# semodule -i mypol.pp
Comment 12 Ralf Corsepius 2008-01-13 00:06:33 EST
(In reply to comment #10)
> You should be able to download selinux-policy-3.0.8-74.fc8 from fedora-testing

With this package installed (and rebooted) has setroubleshootd has survived for
more than 24 hours.

... but now, I am wondering if setroubleshoot-applet is still functional at all.

I am observing sealerts in /var/log/messages, but I don't recall
setroubleshoot-applet to have reported them. Either I have missed them, or there
is more to it - I don't know, yet.
Comment 13 Ralf Corsepius 2008-01-14 02:12:32 EST
(In reply to comment #12)
OK, I think this PR can be closed once *-74 has been pushed. It seems to solve
my dying setroubleshootd issue.

The other issues I am observing don't seem to be related to this issue, but seem
to be more general issues with setroubleshoot's design and usability.
Comment 14 Johan Cwiklinski 2008-02-26 01:52:20 EST
Hi, I have the same problem as the initial : setroubleshoot dies quicly.

Here is what I can see from /var/log/messages when it happens :
Feb 26 07:50:08 odysseus setroubleshoot: [program.ERROR] Can not handle AVC'S
related to dispatcher. exiting#012setroubleshoot
context=unconfined_u:system_r:setroubleshootd_t:s0, AVC
scontext=unconfined_u:system_r:setroubleshootd_t:s0

Versions :
# rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' '*selinux*'
selinux-policy-targeted-3.0.8-84.fc8.noarch
libselinux-2.0.43-1.fc8.x86_64
libselinux-devel-2.0.43-1.fc8.x86_64
selinux-policy-devel-3.0.8-84.fc8.noarch
selinux-policy-3.0.8-84.fc8.noarch
libselinux-2.0.43-1.fc8.i386
libselinux-python-2.0.43-1.fc8.x86_64
Comment 15 Johan Cwiklinski 2008-02-26 01:54:37 EST
Created attachment 295877 [details]
setroubleshoot errors from start to crash
Comment 16 Ralf Corsepius 2008-02-26 02:02:10 EST
(In reply to comment #14)
> Hi, I have the same problem as the initial : setroubleshoot dies quicly.
Are you using mock or other chroots on his machine?
Comment 17 Johan Cwiklinski 2008-02-26 02:30:46 EST
Sometimes, yes, but not when I had these errors.

What is the relation with these issue ?
Comment 18 Ralf Corsepius 2008-02-26 02:54:01 EST
According to reports on various lists, installing rpms into chroots (like mock)
modifies the SELinux contexts of the hosting system instead of ignoring them
rsp. modifying the contexts inside of the chroot.

I.e. mock and SELinux are mutually exclusive. I'd assume this to be the cause of
my initial report and many other issues I had with SELinux.



Comment 19 Johan Cwiklinski 2008-02-26 05:04:25 EST
I'm not sure about this. If installing a package into a chrooted environment
really could change contexts out of this chroot, a simple relabeling should
solve the issue, IMHO.

Anyways, I never had such issues previously, since I always had SELinux
activated and used mock quite often. The first time this problem appears was
yesterday (according to ausearch -m AVC).

I've tried to relabel, problem still persist.

I'll now try to use audit2allow...
Comment 20 Daniel Walsh 2008-02-26 10:42:38 EST
This one looks like an actual bug in setroubleshoot.  Reassigning to package owner.
Comment 21 Bug Zapper 2008-11-26 04:19:14 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 23 Bug Zapper 2009-11-18 07:24:26 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 24 Bug Zapper 2009-12-18 01:02:22 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.