Bug 498391
| Summary: | SELinux prevents HAL (and possibly others) from working | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Sandro Mathys <sandro> | ||||||||
| Component: | selinux-policy-targeted | Assignee: | Daniel Walsh <dwalsh> | ||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | rawhide | CC: | dwlegg, eparis, sdsmall | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2009-05-05 14:18:38 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Sandro Mathys
2009-04-30 09:10:46 UTC
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? 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 192 Unfortunately, I have no idea what I'm looking for in the audit.log - shall I attach it? Yes please attach the audit.log 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. 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. 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 Why did you gte a duplicate declaration? 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.
(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. 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. After executing the given commands, I still suffer from this issue. Please attach a new audit.log? Created attachment 342451 [details]
New audit.log after the issue couldn't be fixed
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 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. Those messages are a result of you running an old kernel with a bug that has been fixed in newer kernels. Created attachment 342458 [details]
New audit.log after latest try
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). 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. New kernel would just fix the messages in comment #15 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 |