4

We recently experienced a power failure and simultaneous backup generator failure, severe enough to require safely shutting down all servers as their UPSs were draining.

Upon bringing one CentOS 7.4.1708 server back up (its first "reboot" in months, but it is up-to-date in terms of CentOS updates) I hit a brick wall preventing me from booting it with SELinux enabled. I have researched extensively but can't seem to find evidence that anyone else has experienced this, nor do I know what to try next. I'm hoping someone here can offer up some ideas.

Here's the timeline:

  1. Booted

  2. Boot failed due to several services not starting up:

    FAILED Failed to start Login Service.
See 'systemctl status systemd-logind.service' for details.
FAILED Failed to start Authorization Manager.
See 'systemctl status polkit.service' for details.
DEPEND Dependency failed for Dynamic System Tuning Daemon.

  3. Prompted by this I rebooted with selinux=0 in grub

  4. This works and gets the system running, but with SELinux disabled which is not viable for us as anything other than a temporary workaround

  5. Followed advice found online:

    sudo yum reinstall selinux-policy-targeted

  6. Rebooted

  7. Boot now failed due to:

    Failed to load SELinux policy, freezing

  8. Rebooted with selinux=0 in grub again

  9. Found more advice so performed:

    sudo yum reinstall selinux-policy-targeted
sudo touch /.autorelabel

    and set permissive in /etc/selinux/config

  10. Rebooted

  11. Could see the following banner:

    Warning -- SELinux targeted policy relabel is required.
Relabeling could take a very long time, depending on file
system size and speed of hard drives.

    but instead of actually performing the relabelling, the system immediately rebooted itself — too fast to see any other output

  12. Boot again failed with the original error.

    So ugh we're back here again. And I can see that /.autorelabel still exists, suggesting the relabel didn't happen. It's surprising to me that we're back to square one with the errors though.

    Also recall that SELinux is still in permissive mode, not enforcing.

The end result is that I'm stuck without being able to enable SELinux in either permissive or enforcing mode, which is not okay.

How should I proceed?

Lightness Races in Orbit
  • 388
  • 2
  • 5
  • 18

5 Answers5

3

tl;dr: Everything came down to an invalid value for SELINUXTYPE.

Make sure SELINUXTYPE has a valid value, then perform relabelling if needed (e.g. if you've booted with SELinux off during your diagnostics), reboot and crack open the champagne.

For some reason, and at some point in time, /etc/selinux/config had acquired the setting SELINUXTYPE=permissive.

This is not a valid option for that parameter, and it appears to make the value fall back on the value "default", based upon the reason listed for why Dbus, Login Service and Authorization Manager failed:

Failed to open "/etc/selinux/default/contexts/dbus_contexts": No such file or directory

This is troublesome because there is no selinux-policy-default package in CentOS 7 (on Debian, for example, it was deliberately removed in Jessie so I'd imagine the same is true here).

I suspect this is also why attempts to relabel the file system using restorecon (from single-user mode, and from a shell reached by init=/sbin/sh) resulted in baffling "No such file or directory" outputs, and getenforce would still show "Disabled" for no evident reason.

To switch to the selinux-policy-targeted stuff which is installed, I fixed the configuration to be SELINUXTYPE=targeted (as I believe it should have been all along), then again rebooted with enforcing=0 autorelabel=1.

The relabelling then took place. Following that, the system booted up as normal.

Lightness Races in Orbit
  • 388
  • 2
  • 5
  • 18
1

You should be able to relabel the filesystem with:

# restorecon -rv /

I'm not 100% sure if that works in Disabled mode, you may need to be in Permissive/Enforcing.

Can you boot with selinux enabled and init=/bin/sh?

MikeyB
  • 39,291
  • 10
  • 105
  • 189
  • You can't restorecon when SELinux is disabled; it has to be at least permissive. – Michael Hampton Dec 13 '17 at 17:36
  • This solution didn't work for me, but that was a baffling state of affairs that helped me deduce what was causing not only the root problem, but the problem with all of my would-be remedial steps. Thanks for your help! – Lightness Races in Orbit Dec 14 '17 at 14:51
0

You should it have booted to recovery mode then root shell terminal and put disabled=1 then resume without rebooting then disable it on config file... Then uninstall selinux then restart

Ronald Campos
  • 1
0

To solve this issue I completely removed SELinux using

sudo yum remove selinux*

Once removed I reinstalled selinux

sudo yum install selinux*

then rebooted in passive mode. Once the policy was loaded, I then changed to enforcing and rebooted again Just removing the policy and reinstalling plus creating the /.autorelabel didn't work. This was the only was I could get round the policy not loading.

Andy
  • 1
-1

Sometimes the same problem can be encountered because of SELinux policy even if SELinuxtype setted correctly. And at boot screen following line shows up:
Failed to load SELinux policy, freezing
To solve this problem as another workaround you can set SELinux to permissive mode first
then reboot machine, and you will see that SELinux generating policy on the reboot screen. After that you can set it to enforcing mode again without problem.

Before solving the problem you can check policy devel package.
sudo yum install policycoreutils-devel
And perhaps you will get an error when tyr to install it. This is beacuse of conflict packages mostly and still comes out even for Red Hat 8

shnoq
  • 1
  • 2
  • Question was answered years ago. The root cause was SELINUXTYPE was not correctly set. – Jeter-work Mar 18 '20 at 15:33
  • Sometimes same problem can be encountered because of SELinux policy, that is why I added this one as another solution. – shnoq Mar 23 '20 at 14:28