☰

SELinux beschädigt? Jetzt kann CentOS 7 mit aktiviertem SELinux nicht mehr gebootet werden

tag-icon • tag-icon centos selinux
SELinux beschädigt? Jetzt kann CentOS 7 mit aktiviertem SELinux nicht mehr gebootet werden

Wir hatten vor Kurzem einen Stromausfall und gleichzeitig einen Ausfall des Notstromgenerators. Dieser war so schwerwiegend, dass alle Server aufgrund der Entladung ihrer USVs sicher heruntergefahren werden mussten.

Als ich einen CentOS 7.4.1708-Server wieder hochgefahren habe (es war der erste „Neustart“ seit Monaten, aber er ist in Bezug auf CentOS-Updates auf dem neuesten Stand), stieß ich auf eine Mauer, die mich daran hinderte, ihn mit aktiviertem SELinux zu booten. Ich habe ausführlich recherchiert, kann aber anscheinend keine Beweise dafür finden, dass jemand anderes dies erlebt hat, und ich weiß auch nicht, was ich als nächstes versuchen soll. Ich hoffe, dass jemand hier einige Ideen anbieten kann.

Hier ist die Zeitleiste:

  1. Gebootet

  2. Der Startvorgang ist fehlgeschlagen, da mehrere Dienste nicht gestartet wurden:

    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. Angeregt durchDasIch habe mit selinux=0in grub neugestartet

  4. Dies funktioniert und bringt das System zum Laufen, allerdings mit deaktiviertem SELinux, was für uns nur eine vorübergehende Problemumgehung darstellt.

  5. GefolgtRatschläge online gefunden:

    sudo yum reinstall selinux-policy-targeted

  6. Neugestartet

  7. Der Start ist aufgrund von Folgendem fehlgeschlagen:

    Failed to load SELinux policy, freezing

  8. selinux=0Wieder mit in Grub neugestartet

  9. Gefundenweitere Tippsso durchgeführt:

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

    und setzen freizügig in/etc/selinux/config

  10. Neugestartet

  11. Könnte das folgende Banner sehen:

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

    aber anstatt die Umbenennung tatsächlich durchzuführen, startete sich das System sofort neu – zu schnell, um eine andere Ausgabe zu sehen

  12. Der erneute Start schlug mit dem ursprünglichen Fehler fehl.

    Also, pfui, da sind wir schon wieder. Und ich sehe, dass das /.autorelabelimmer noch da ist, was darauf hindeutet, dass die Umbenennung nicht stattgefunden hat. Es überrascht mich allerdings, dass wir mit den Fehlern wieder am Anfang stehen.

    Denken Sie auch daran, dass SELinux sich noch im permissiven Modus befindet und nicht erzwingt.

Das Endergebnis ist, dass ich nicht weiterkomme und SELinux weder im permissiven noch im erzwingenden Modus aktivieren kann, was nicht in Ordnung ist.

Wie soll ich vorgehen?

Antwort1

kurz und knapp:Alles lief auf einen ungültigen Wert für hinaus SELINUXTYPE.

Stellen Sie sicher SELINUXTYPE, dass ein gültiger Wert vorhanden ist, und führen Sie dann bei Bedarf eine Neubeschriftung durch (z. B. wenn Sie während Ihrer Diagnose mit deaktiviertem SELinux gebootet haben), starten Sie neu und lassen Sie den Champagner aufgehen.

Aus irgendeinem Grund und zu einem bestimmten Zeitpunkt /etc/selinux/confighatte ich die Einstellung erworben SELINUXTYPE=permissive.

Dies ist keine gültige Option für diesen Parameter und scheint dazu zu führen, dass der Wert auf den Wert „default“ zurückgesetzt wird, basierend auf dem aufgeführten Grund, warum Dbus, Login Service und Authorization Manager fehlgeschlagen sind:

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

selinux-policy-defaultDies ist problematisch, da es in CentOS 7 kein Paket gibt (unter Debian wurde es beispielsweise in Jessie absichtlich entferntdaher könnte ich mir vorstellen, dass das Gleiche hier der Fall ist).

Ich vermute, dies ist auch der Grund, warum Versuche, das Dateisystem mit neu zu benennen restorecon(aus dem Einzelbenutzermodus und von einer Shell aus, auf die über zugegriffen werden konnte init=/sbin/sh), zu verwirrenden Ausgaben wie „Keine solche Datei oder kein solches Verzeichnis“ führten und getenforceweiterhin ohne ersichtlichen Grund „Deaktiviert“ angezeigt wurde.

Um zu dem selinux-policy-targetedZeug zu wechseln, dasIstinstalliert, ich habe die Konfiguration so korrigiert, dass sie war SELINUXTYPE=targeted(wie sie meiner Meinung nach die ganze Zeit hätte sein sollen), und dann erneut mit neugestartet enforcing=0 autorelabel=1.

Anschließend erfolgte die Umbenennung. Anschließend bootete das System normal.

Antwort2

Sie sollten in der Lage sein, das Dateisystem mit folgendem Befehl neu zu benennen:

# restorecon -rv /

Ich bin nicht 100 % sicher, ob das im deaktivierten Modus funktioniert. Möglicherweise müssen Sie sich im Permissive/Enforcing-Modus befinden.

Können Sie mit aktiviertem Selinux booten und init=/bin/sh?

Antwort3

Sie sollten es in den Wiederherstellungsmodus gebootet haben, dann das Shell-Terminal rooten und disabled=1 setzen, dann ohne Neustart fortfahren und es dann in der Konfigurationsdatei deaktivieren... Dann Selinux deinstallieren und neu starten

Antwort4

Manchmal kann das gleiche Problem aufgrund der SELinux-Richtlinie auftreten, selbst wenn der SELinux-Typ richtig eingestellt ist. Und auf dem Startbildschirm wird folgende Zeile angezeigt:
Failed to load SELinux policy, freezing
Um dieses Problem zu lösen, können Sie als weitere Problemumgehung permissivezuerst SELinux in den -Modus setzen
und dann die Maschine neu starten. Auf dem Neustartbildschirm sehen Sie dann, dass SELinux die Richtlinie generiert. Danach können Sie es problemlos wieder in den Durchsetzungsmodus versetzen.

Bevor Sie das Problem lösen, können Sie das Paket „Policy Devel“ überprüfen.
sudo yum install policycoreutils-devel
Möglicherweise erhalten Sie beim Versuch, es zu installieren, eine Fehlermeldung. Dies liegt hauptsächlich an Paketkonflikten und tritt auch bei Red Hat 8 immer noch auf.

verwandte Informationen