Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 232368 - cannot boot with enforcing
Summary: cannot boot with enforcing
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 6
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-15 01:02 UTC by cje
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-16 04:01:04 UTC


Attachments (Terms of Use)

Description cje 2007-03-15 01:02:31 UTC
Description of problem:
something has gone wrong with selinux and now i get selinux denials for just
about everything and the boot drops me to a maintenance command line.  i can't
find any way to restore the system.  (eveything runs fine with permissive or
disabled.)

in permissive, here's the first few lines of selinux stuff in the system log:

Mar 15 00:47:20 desk kernel: audit(1173919581.873:2): policy loaded auid=4294967295
Mar 15 00:47:20 desk kernel: audit(1173919582.681:3): avc:  denied  { read } for
 pid=406 comm="mount" name="libblkid.so.1.0" dev=dm-0 ino=57376823
scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:samba_share_t:s0 tclass=file
Mar 15 00:47:20 desk kernel: audit(1173919582.693:4): avc:  denied  { getattr }
for  pid=406 comm="mount" name="libblkid.so.1.0" dev=dm-0 ino=57376823
scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:samba_share_t:s0 tclass=file
Mar 15 00:47:20 desk kernel: audit(1173919582.701:5): avc:  denied  { execute }
for  pid=406 comm="mount" name="libblkid.so.1.0" dev=dm-0 ino=57376823
scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:samba_share_t:s0 tclass=file
Mar 15 00:47:20 desk kernel: audit(1173919585.185:6): avc:  denied  { search }
for  pid=432 comm="hwclock" name="/" dev=dm-0 ino=2
scontext=system_u:system_r:hwclock_t:s0
tcontext=system_u:object_r:samba_share_t:s0 tclass=dir
Mar 15 00:47:20 desk kernel: audit(1173919589.394:7): avc:  denied  { search }
for  pid=510 comm="pam_console_app" name="/" dev=dm-0 ino=2
scontext=system_u:system_r:pam_console_t:s0-s0:c0.c1023
tcontext=system_u:object_r:samba_share_t:s0 tclass=dir

i've tried a complete restorecon.  i've switched selinux on and off and that's
caused a lengthy relabel.  i've even tried uninstalling and reinstalling the
selinux-policy packages (which caused another relabel) but it makes no difference.

help!

Version-Release number of selected component (if applicable):
2.4.6-42.fc6

Comment 1 Daniel Walsh 2007-03-16 04:01:04 UTC
This looks like you have something badly labeled as samba_share_t.

fixfiles -F restore 
should clean up the file context.

Did you label something major as samba_share_t?

Comment 2 cje 2007-03-16 07:20:04 UTC
ooh.  that looks like it's done something!  i've got 3087 "Setfiles: relabeling"
messages in my system log now!

how is that different from the 'complete relabelling of entire filesystem'
that's happened twice already during booting when changing selinux modes?

anyway, yes "/" has been relabeled from samba_share_t to root_t by fixfiles. 
it's possible i tried to add a samba share of '/' at some point.  (wouldn't
expect that to render my system unbootable/insecure/whatever without a warning!)
 i'm pretty sure i haven't done any command-line stuff to relabel anything ..
wouldn't know how and doubt i'd risk guessing - this is my main server.

of those 3087 relabels i'd say about 10% are from samba_share_t.  the rest are
almost all from user_u to system_u.  there are a few others including some from
"root" to system_u.

any idea at all what might have caused this?  a lot of the files in the list are
ones installed from non-standard repositories or copied from another system or
installed from tarballs.  also i've run the xen kernel (just dom0) for a while
(including yum updates including selinux updates) and then switched back to
non-xen.  could that affect things?

well, the last 'denied' message was six minutes before the fixfiles and that was
over an hour ago (it was logging about one denial per minute) so i'm off to reboot.

many thanks.


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