Description of problem: When SELinux is set to enforced boot hangs Version-Release number of selected component (if applicable): selinux-policy-3.2.4-2.fc9 How reproducible: Set SELinux to enforced, and reboot Steps to Reproduce: 1.Set SELinux to Enforced 2.Reboot 3. Actual results: Hangs wit a kernel panic (with no relabelling), if I use parameter selinux=0, it boots fine Expected results: Normal boot Additional info:
Where does it hang? Does it happen after it gives the "Welcome to Fedora" message and starts udev? If you're not seeing bootup messages, remove "rhgb quiet" from the boot commandline (which you can edit by hitting "a" at the boot screen)
Can you try to boot with enforcing=0 autorelabel on the boot line. This will cause the machine to relabel in permissive mode. Then see if it can reboot in enforcing mode.
I want to add my $.02 to this as well. When the computer starts in enforcing mode, without enforcing=0 every time, the machine autorelabels itself. However, when trying to login, the login prompts appears again and again (recursively) even with the correct login name and password. This could be related to the other bug https://bugzilla.redhat.com/show_bug.cgi?id=383571 When starting up, I use enforcing=0 and boot into level 3, otherwise I cannot login and I have to restart machine again. [olivares@localhost ~]$ rpm -qa selinux* [olivares@localhost ~]$ rpm -qa selinux-* selinux-policy-devel-3.2.4-2.fc9 selinux-policy-targeted-3.2.4-2.fc9 selinux-policy-3.2.4-2.fc9 [olivares@localhost ~]$ Let me know what I can try except the above. It does not work for me. I have tried and it failed miserably :(
This problem is actually caused by hal crashing. Hal is trying to read a polickit file in /var/lib/misc directory. I have an open bug report against PolicyKit to put this file in /var/lib/PolicyKit-public directory. selinux-policy-devel-3.2.5-1.fc9 Will then allow hal and policy kit to work.
The hal bug, which no. is it, so I can add the following: Summary SELinux is preventing /usr/sbin/hald (hald_t) "read" to <Unknown> (system_crond_var_lib_t). Detailed Description SELinux denied access requested by /usr/sbin/hald. It is not expected that this access is required by /usr/sbin/hald and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for <Unknown>, restorecon -v <Unknown> If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context unconfined_u:system_r:hald_t Target Context system_u:object_r:system_crond_var_lib_t Target Objects None [ file ] Affected RPM Packages hal-0.5.10-3.fc9 [application] Policy RPM selinux-policy-3.2.5-2.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name localhost Platform Linux localhost 2.6.24-0.115.rc5.git5.fc9 #1 SMP Tue Dec 18 23:57:17 EST 2007 i686 athlon Alert Count 2 First Seen Fri 21 Dec 2007 01:49:40 PM CST Last Seen Fri 21 Dec 2007 01:49:53 PM CST Local ID c4301741-d5e1-42f5-9c6d-0008aeef8586 Line Numbers Raw Audit Messages avc: denied { read } for comm=hald dev=dm-0 egid=0 euid=0 exe=/usr/sbin/hald exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=PolicyKit.reload pid=30320 scontext=unconfined_u:system_r:hald_t:s0 sgid=0 subj=unconfined_u:system_r:hald_t:s0 suid=0 tclass=file tcontext=system_u:object_r:system_crond_var_lib_t:s0 tty=(none) uid=0 It now makes sense that haldeamon does not run because selinux prevents it from doing so: [root@localhost ~]# service haldaemon status hald is stopped [root@localhost ~]# service haldaemon start Starting HAL daemon: [FAILED] [root@localhost ~]# service haldaemon stop Stopping HAL daemon: [FAILED] [root@localhost ~]# service haldaemon restart Stopping HAL daemon: [FAILED] Starting HAL daemon: [FAILED] [root@localhost ~]# I have to add this, since I previously had to login via level 3 and uisng enforcing=0 parameter. I can now see what you mean, is this against hal, or policykit? Thanks, Antonio
hald.
CLosed as this should be fixed in rawhide. If this problem persists please reopen the bugzilla.