Bug 427721

can you attach the output of ausearch -m AVC (possibly with -ts recent if it is
too long)

Created attachment 290977 [details]
output of ausearch -m AVC near to the time of the incident reported above

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).

(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?

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

.autorelabel didn't really help.

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

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.

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)]

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?

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

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

(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.

(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.

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

Created attachment 295877 [details]
setroubleshoot errors from start to crash

(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?

Sometimes, yes, but not when I had these errors.

What is the relation with these issue ?

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.

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...

This one looks like an actual bug in setroubleshoot.  Reassigning to package owner.

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

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

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.