Bug 156765 - upgrade with selinux disabled borks file contexts
upgrade with selinux disabled borks file contexts
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-04 00:59 EDT by Jonathan S. Shapiro
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 1.25.4-10.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-15 11:56:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan S. Shapiro 2005-05-04 00:59:04 EDT
While messing around with xen, I set selinux to disabled in the
/etc/selinux/config file so that I could build a xen guest image.

Unthinkingly, I did an upgrade using yum while in selinux=disabled state.

I later reset the config file to selinux=enforcing and rebooted. Oh boy was this
a mistake.

Needless to say, the reboot was completely unsuccessful past initstate 1.

Recovering from this was quite a chore, and took several attempts. My final
resolution was:

1. Reboot to initstate s
2. Change selinux mode to permissive, because restorecon cannot be executed in
selinux=disabled mode.
3. Reboot, this time to initstate 3 so that selinux became active
4. run "restorecon -v -R /"
5. Now set selinux to enforcing in the config file
6. reboot for real

This REALLY needs to be documented. It might be wise to have a kernel command
line option that will be picked up in rc.sysinit EARLY in the init scripts
(immediately after local FS mountall) that will cause restorecon to be run on
the entire system at that point before any further bits of system initialization
are run..

The fact that I was messing around with xen is really not the point. The point
is that some dingbat out there will upgrade with selinux disabled and really
regret it.
Comment 1 Jonathan S. Shapiro 2005-05-04 01:09:07 EDT
Hell. It's more of a nuisance than I thought. One actually needs to run

  restorecon -R -v / -e /misc -e /net

or else one gets "operation not supported" on /misc, /net

Which raises a question. Why don't

  restorecon /misc
  restorecon /net

work?
Comment 2 Daniel Walsh 2005-05-05 07:33:39 EDT
Because they are file systems that do not support extented attributes.  The best
way to relabel is to 
touch /.autorelabel; reboot

This is in the documentation.  If you are going to run SELinux and you want to
stop enforcing mode you can type 
setenforce 0
Then you could play with Xen.  This will maintain the security contexts.  If you
want this to me maintained on reboot, set enforcing mode to permissive in 
/etc/selinux/config.
Comment 3 Jonathan S. Shapiro 2005-05-05 10:11:35 EDT
What file systems are you talking about? I think you did not read the bug
report. Xen was incidental to this bug -- it was merely the thing that caused me
to discover it.

You can repeat this bug by:

1. Install FC3/FC4 from CD. Activate selinux during install. So far so good.
2. Disable selinux and reboot
3. Run yum update.
4. Renable selinux and reboot

The problem here is not that the file system lacks the ability to support
extended attributes. It is the same file system that the original
selinux-enabled system was installed on in the first place. The problem is that
chcon and friends did not operate during step 3 (and *could* not, since selinux
was disabled).

And yes, all of this is documented behavior, but that does not justify closing
the bug. Think about the consequence in step 4: user now has an unbootable
system. That is unquestionably a bug. Documenting it does not turn it into a
feature.

My concrete suggestion for how to address this is as follows:

1. Modify the system shutdown process to record whether selinux was running at
the time of shutdown -- perhaps based on sestatus -v

2. On reboot, if selinux is NOW enabled and was not enabled at last shutdown,
run restorecon very early in the reboot process.
Comment 4 Daniel Walsh 2005-05-12 12:57:23 EDT
Fixed in initscripts-8.11-1
Anytime you boot with selinux=0 it will create the /.autorelabel flag.

Next time you boot with selinux enabled, it will relabel
Comment 5 Jonathan S. Shapiro 2005-05-12 13:42:22 EDT
I note that initscripts-8.11-1 is not yet in the devel tree. Is it anticipated
to make the cut for FC4?

Not that it matters - just idly curious. I think it's important to get this
update out fairly soon, but it's definitely not a "hold the release" issue.
Comment 6 Daniel Walsh 2005-05-12 13:48:05 EDT
Looks like it will be in FC4.
Comment 7 Jonathan S. Shapiro 2005-09-15 12:16:24 EDT
Daniel: thank you for your efforts on this.

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