Bug 498391 - SELinux prevents HAL (and possibly others) from working
SELinux prevents HAL (and possibly others) from working
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2009-04-30 05:10 EDT by Sandro Mathys
Modified: 2009-05-05 10:18 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-05 10:18:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
audit.log of a system affected by the issue (4.74 MB, text/plain)
2009-05-01 05:41 EDT, Sandro Mathys
no flags Details
New audit.log after the issue couldn't be fixed (968.04 KB, text/plain)
2009-05-05 08:48 EDT, Sandro Mathys
no flags Details
New audit.log after latest try (1.18 MB, text/plain)
2009-05-05 09:30 EDT, Sandro Mathys
no flags Details

  None (edit)
Description Sandro Mathys 2009-04-30 05:10:46 EDT
Description of problem:
I installed all updates from rawhide that were new since yesterday (CEST). For some reasons, I did a reboot after that. But when booting up again, HAL wasn't able to start. I was able to work around this problem by setting SELinux to permissive.

Version-Release number of selected component (if applicable):
$ rpm -qa selinux*

How reproducible:
Always (boot with selinux=enforcing->problem). Didn't try updating selinux on another system or down- and again upgrading this system.

Steps to Reproduce:
1. Upgrade to the latest rawhide
2. reboot
3. enjoy no HAL (i.e. no network, no mouse, no usable X)
Actual results:
HAL can't start

Expected results:
Everything works smoothly.

Additional info:
I noticed something strange during boot:
# grep SELinux /var/log/dmesg | grep unmapped
SELinux:  Context system_u:object_r:devicekit_var_run_t:s0 is not valid (left unmapped).
SELinux:  Context system_u:object_r:svirt_var_run_t:s0 is not valid (left unmapped).
Comment 1 Daniel Walsh 2009-04-30 07:49:13 EDT
I have no have no idea where thos messages come from.

Those contexts are valid in the policy, I you sure SELinux is causing the hal problem?  Do you see any AVC's in /var/log/audit/audit.log?  Can you boot and login in permissive mode?
Comment 2 Sandro Mathys 2009-04-30 08:02:25 EDT
I concluded that SELinux is causing the hal problem since hal doesn't work in enforcing mode but does in permissive mode (so yes, I can boot like that and everything works fine).

Lots of AVC (never seen an audit.log without lots of AVC). Filtering those about hal out:
# grep -i hald audit.log | wc -l

Unfortunately, I have no idea what I'm looking for in the audit.log - shall I attach it?
Comment 3 Daniel Walsh 2009-04-30 08:24:42 EDT
Yes please attach the audit.log
Comment 4 Stephen Smalley 2009-04-30 08:27:49 EDT
The kernel messages mean that those contexts were not valid under the currently loaded policy.  If the new policy package does in fact define them, then possibly something went wrong during %post and semodule/libsemanage rolled back to the prior policy.  That's a general problem with doing semodule from %post - there is no rollback of the rpm transaction if something goes wrong there.
Attaching /var/log/yum.log and /var/log/audit/audit.log might be helpful.
Comment 5 Stephen Smalley 2009-04-30 09:33:06 EDT
For example, in trying to perform a yum update from F10 to current rawhide, I get the following while updating selinux-policy-targeted:
libsepol.scope_copy_callback: audioentropy: Duplicate declaration in module: type/attribute entropyd_var_run_t
libsemanage.semanage_link_sandbox: Link packages failed
semodule:  Failed!

As a result, I'm left with the old policy but rpm thinks it has the new policy installed because the failure happens in %post and nothing gets rolled back.  Hurray for rpm not being aware of policy at all.
Comment 6 Stephen Smalley 2009-04-30 10:37:46 EDT
My workaround in that situation btw is to:
yum remove selinux-policy-targeted
mv /etc/selinux/targeted/modules /etc/selinux/targeted/modules.old
yum install selinux-policy-targeted
Comment 7 Daniel Walsh 2009-04-30 17:41:45 EDT
Why did you gte a duplicate declaration?
Comment 8 Sandro Mathys 2009-05-01 05:41:06 EDT
Created attachment 342061 [details]
audit.log of a system affected by the issue

Here's my audit.log - sorry I wasn't able to attach it earlier.
Comment 9 Stephen Smalley 2009-05-01 07:32:34 EDT
(In reply to comment #7)
> Why did you gte a duplicate declaration?  

I don't know, although I assume you can replicate it just by doing an update from F10 to rawhide.  I expect that it means that the type was already defined in a module in the F10 policy but was moved (or renamed) into a different module in F11 policy, but the old module got left around.  The current approach of running semodule -i on /usr/share/selinux/targeted/*.pp doesn't deal with leftover modules from the old policy that were previously installed; it only replaces and/or adds modules from the new policy.
Comment 10 Daniel Walsh 2009-05-01 08:38:20 EDT
Sandro, Could you try to reinstall selinux-policy-targeted with the --force command.   Looks like the failures caused the policy to not load.  Also looks like you have some mislabeled file in /etc.

# setenforce 0
# yum reinstall selinux-policy-targeted
# fixfiles restore

Should clean it up.

Stephen, it is not exactly installing semodule -i on /usr/share/selinux/targeted/*.pp
It is really installing all the modules listed in the modules.conf, And I agree that removing a pp file is difficult.  So I try not to, or put a removal into the post install.
Comment 11 Sandro Mathys 2009-05-05 02:58:21 EDT
After executing the given commands, I still suffer from this issue.
Comment 12 Daniel Walsh 2009-05-05 08:41:07 EDT
Please attach a new audit.log?
Comment 13 Sandro Mathys 2009-05-05 08:48:34 EDT
Created attachment 342451 [details]
New audit.log after the issue couldn't be fixed
Comment 14 Daniel Walsh 2009-05-05 08:58:05 EDT
I see no evidence that the policy was loaded.

# setenforce 0
# yum reinstall selinux-policy-targeted
# fixfiles restore

Did these commands succeed?  
I should have told you to reboot.

If yes, can you reboot the system and see if the AVC's stop being generated
Comment 15 Sandro Mathys 2009-05-05 09:18:03 EDT
They did succeed, yes. I did a reboot between applying those commands and getting back to this ticket, yes. Not immediately after executing those, though.

I just did execute those 3 commands again. While doing so, kerneloops ask me several times to send information to the kernel developers, the information always showing lines as such:

SELinux: WARNING: inside open_file_mask_to_av with unknown mode:c1b6
SELinux: WARNING: inside open_file_mask_to_av with unknown mode:c1ff
SELinux: WARNING: inside open_file_mask_to_av with unknown mode:c1fd

I only paste every 'unknown mode' once here, but they all appear lots of times.

I'll now do a reboot and then attach the audit.log again.
Comment 16 Eric Paris 2009-05-05 09:28:00 EDT
Those messages are a result of you running an old kernel with a bug that has been fixed in newer kernels.
Comment 17 Sandro Mathys 2009-05-05 09:30:29 EDT
Created attachment 342458 [details]
New audit.log after latest try
Comment 18 Sandro Mathys 2009-05-05 09:38:37 EDT
Eric: oh, I see. Does this only affect those messages or the whole problem we're discussing here? Pity I can't update to the latest and greatest kernel because my system won't run with it (there's another bz open for that).
Comment 19 Daniel Walsh 2009-05-05 09:48:46 EDT
Sandro can you ping me on IRC FreeNode #selinux

Something is very strange on your machine.  I see lots of mislabeled files 

Also can you update to policy -28 which was released yesterday.
Comment 20 Eric Paris 2009-05-05 09:55:32 EDT
New kernel would just fix the messages in comment #15
Comment 21 Daniel Walsh 2009-05-05 10:17:00 EDT
I believe this is being caused by using the F10 kernel/initrd.  The problem is on reboot you are reloading the old policy.23 (f10 policy) instead of the new policy.24 (F11 policy).  You could either change /etc/selinux/semanage.conf to build policy.24 or rebuild

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