¿SELinux está dañado? Ahora no se puede iniciar CentOS 7 con SELinux habilitado

¿SELinux está dañado? Ahora no se puede iniciar CentOS 7 con SELinux habilitado

Recientemente experimentamos un corte de energía y un fallo simultáneo del generador de respaldo, lo suficientemente grave como para requerir el apagado seguro de todos los servidores mientras sus UPS se estaban agotando.

Al hacer una copia de seguridad de un servidor CentOS 7.4.1708 (su primer "reinicio" en meses, pero está actualizado en términos de actualizaciones de CentOS), choqué contra una pared que me impedía iniciarlo con SELinux habilitado. He investigado extensamente pero parece que no puedo encontrar evidencia de que alguien más haya experimentado esto, ni sé qué intentar a continuación. Espero que alguien aquí pueda ofrecer algunas ideas.

Aquí está la línea de tiempo:

  1. Arrancado
  2. El arranque falló debido a que varios servicios no se iniciaron:

    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. Provocado poresteReinicié con selinux=0grub

  4. Esto funciona y hace que el sistema funcione, pero con SELinux deshabilitado, lo cual no es viable para nosotros más que como una solución temporal.

  5. Seguidoconsejos encontrados en línea:

    sudo yum reinstall selinux-policy-targeted
    
  6. Reiniciado

  7. El arranque ahora falló debido a:

    Failed to load SELinux policy, freezing
    
  8. Reiniciado con selinux=0grub nuevamente

  9. Encontrómás consejosasí realizado:

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

    y establecer permisivo en/etc/selinux/config

  10. Reiniciado

  11. Pude ver el siguiente 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.
    

    pero en lugar de realizar el reetiquetado, el sistema se reinició inmediatamente, demasiado rápido para ver cualquier otro resultado.

  12. El arranque nuevamente falló con el error original.

    Así que estamos de vuelta aquí otra vez. Y puedo ver que /.autorelabeltodavía existe, lo que sugiere que la nueva etiqueta no ocurrió. Sin embargo, me sorprende que volvamos al punto de partida con los errores.

    Recuerde también que SELinux todavía está en modo permisivo, no aplicando.

El resultado final es que estoy atascado sin poder habilitar SELinux ni en modo permisivo ni en modo obligatorio, lo cual no está bien.

¿Cómo debo proceder?

Respuesta1

tl;dr:Todo se redujo a un valor no válido para SELINUXTYPE.

Asegúrese de SELINUXTYPEque tenga un valor válido, luego vuelva a etiquetar si es necesario (por ejemplo, si arrancó con SELinux apagado durante el diagnóstico), reinicie y abra el champán.


Por alguna razón, y en algún momento, /etc/selinux/confighabía adquirido el escenario SELINUXTYPE=permissive.

Esta no es una opción válida para ese parámetro y parece hacer que el valor vuelva al valor "predeterminado", según el motivo enumerado por el cual fallaron Dbus, el servicio de inicio de sesión y el administrador de autorización:

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

Esto es problemático porque no hay ningún selinux-policy-defaultpaquete en CentOS 7 (en Debian, por ejemplo, se eliminó deliberadamente en Jessieasí que me imagino que lo mismo ocurre aquí).

Sospecho que esta es también la razón por la que los intentos de volver a etiquetar el sistema de archivos usando restorecon(desde el modo de usuario único y desde un shell al que accede init=/sbin/sh) dieron como resultado resultados desconcertantes de "No existe tal archivo o directorio", y getenforceaún mostrarían "Desactivado" sin ninguna razón evidente. .

Para cambiar a las selinux-policy-targetedcosas queesinstalado, arreglé la configuración SELINUXTYPE=targeted(como creo que debería haber sido desde el principio) y luego reinicié nuevamente con enforcing=0 autorelabel=1.

A continuación tuvo lugar el reetiquetado. Después de eso, el sistema se inició normalmente.

Respuesta2

Debería poder volver a etiquetar el sistema de archivos con:

# restorecon -rv /

No estoy 100% seguro de si eso funciona en modo Desactivado, es posible que tengas que estar en Permisivo/Aplicando.

¿Puedes arrancar con selinux habilitado y init=/bin/sh?

Respuesta3

Debería haber arrancado en modo de recuperación, luego rootear el terminal shell y poner deshabilitado = 1, luego reanudarlo sin reiniciar y luego deshabilitarlo en el archivo de configuración... Luego desinstale selinux y luego reinicie.

Respuesta4

A veces se puede encontrar el mismo problema debido a la política de SELinux incluso si SELinuxtype está configurado correctamente. Y en la pantalla de inicio aparece la siguiente línea:
Failed to load SELinux policy, freezing
Para resolver este problema como otra solución, primero puede configurar SELinux en permissivemodo
y luego reiniciar la máquina, y verá que SELinux genera la política en la pantalla de reinicio. Después de eso, puedes volver a configurarlo en modo forzado sin problemas.

Antes de resolver el problema, puede consultar el paquete de desarrollo de políticas.
sudo yum install policycoreutils-devel
Y tal vez reciba un error cuando intente instalarlo. Esto se debe principalmente a paquetes conflictivos y todavía aparece incluso para Red Hat 8.

información relacionada