Bug 426092 - SELinux prevents booting
Summary: SELinux prevents booting
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-18 14:01 UTC by antonio montagnani
Modified: 2008-03-05 22:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-03-05 22:19:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description antonio montagnani 2007-12-18 14:01:02 UTC
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:

Comment 1 Will Woods 2007-12-18 14:57:31 UTC
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)

Comment 2 Daniel Walsh 2007-12-18 15:15:45 UTC
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.

Comment 3 Antonio A. Olivares 2007-12-19 13:35:08 UTC
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 :(

Comment 4 Daniel Walsh 2007-12-19 18:25:37 UTC
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.

Comment 5 Antonio A. Olivares 2007-12-21 20:07:58 UTC
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 

Comment 6 Daniel Walsh 2007-12-31 19:12:15 UTC
hald.

Comment 7 Daniel Walsh 2008-03-05 22:19:03 UTC
CLosed as this should be fixed in rawhide.  If this problem persists please
reopen the bugzilla.


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