SELinux restablecer contraseña de root

12

Descargo de responsabilidad: Esta pregunta no es para resolver el problema de cambiar la contraseña de root mientras SELinux está activo porque ya hay muchas guías para resolverlo. Esto es más de cómo SELinux lo hace internamente.

Soy un usuario reciente de SELinux, pero últimamente he estado más en contacto con él. Hubo un momento en que alguien me preguntó cómo podría restablecer la contraseña de root en caso de olvidarla.

Así que inicié mi CentOS, edité la entrada de grub a algo como

linux16 <kernel_location> root=/dev/mapper/centos-root rw init=/bin/bash

Corrí passwdy luego corrí syncy forcé el reinicio. Después de reiniciar, se rechazó el inicio de sesión con la nueva contraseña, así como con la antigua, por supuesto.

Reinició nuevamente y le pasó al kernel el parámetro para deshabilitar SELinux ( selinux=0). Intenté iniciar sesión con la nueva contraseña y funcionó. Luego forcé una etiqueta automática fs (a través del archivo .autorelabel) y con SELinux activo ahora era posible iniciar sesión.

Mi pregunta es: ¿por qué sucede? ¿Por qué el reetiquetado afecta el inicio de sesión cuando solo hubo un cambio de contraseña y no de usuarios u objetos?

Gracias por su atención.

TL; DR: el restablecimiento de contraseña de root habitual no funciona en SELinux. ¿Por qué?

Editar: Esto se probó en una máquina virtual que ejecuta CentOS7 con KVM como hipervisor.

centos redhat password selinux Jorge Heleno
fuente
1
¿Estás seguro de que no funciona? Pruébalo otra vez. Probablemente funcionará bien. Sospecho que simplemente tuvo contextos de archivo incorrectos en algunos archivos, haciendo que todos los inicios de sesión fallen. Por lo tanto, la etiqueta automática fue lo que realmente solucionó el problema.
Michael Hampton
@MichaelHampton Acabo de volver sobre todos mis pasos haciéndolo nuevamente y no pude volver a iniciar sesión con SELinux activo. Después de deshabilitarlo, podría iniciar sesión sin problemas. Corrígeme si me equivoco, pero cambiar una contraseña no debería cambiar los contextos de archivo, ¿verdad?
Jorge Heleno
1
No, no debería. Parece que has descubierto algo extraño e inesperado.
Michael Hampton

Respuestas:

17

Pude duplicar este problema en un sistema CentOS 7.5 recién instalado.

Esto es lo que está pasando:

Cuando arrancas init=/bin/bashhay dos problemas con los que te puedes encontrar:

  • El sistema de archivos raíz puede montarse de solo lectura. En este caso passwdse quejará de un Authentication token manipulation error.

    Esto es bastante obvio: si el sistema de archivos no está montado lectura-escritura, no es posible escribir en él.

  • La política de SELinux no se puede cargar. En este caso passwdcambiará con éxito la contraseña, pero tendrá el problema descrito en la pregunta original anterior: nadie podrá iniciar sesión.

    Los hashes de contraseña se almacenan en el /etc/shadowarchivo. Este archivo normalmente tiene el tipo SELinux shadow_t. Sin embargo, cambiar el archivo mientras no se carga ninguna política SELinux hace que el tipo SELinux se elimine del archivo, dejándolo como unlabeled_t. Por lo tanto, los servicios que intentan leer el archivo para autenticar los inicios de sesión ya no pueden leerlo.

Para cambiar la contraseña de root en RHEL / CentOS 7, debe seguir este proceso:

  1. Agregue init=/bin/bashal final de la línea de comando del núcleo en grub, como lo hizo anteriormente.
  2. En el indicador bash, cargue la política SELinux con /usr/sbin/load_policy -i.
  3. Montar el sistema de archivos raíz de lectura-escritura con mount -o remount,rw /.
  4. Ahora cambie la contraseña y tendrá éxito. passwd root
  5. Vuelva a montar el sistema de archivos de solo lectura para confirmar los cambios y tener un sistema de archivos limpio en el próximo arranque con mount -o remount,ro /.
  6. Salga del shell o reinicie el sistema con exec /sbin/init 6.

Ahora puede iniciar sesión con la contraseña de root modificada.

Red Hat ofrece una explicación más detallada de este procedimiento (se requiere suscripción).

Michael Hampton
fuente
El problema estaba en las políticas que no se cargaron. ¿Por qué no se cargan? SELinux debería funcionar a nivel del núcleo, por lo que no debería ser necesario el sistema init.
Jorge Heleno
44
@JorgeHeleno SELinux está activado o desactivado de manera predeterminada cuando se inicia el kernel, pero el usuario es responsable de decidir qué políticas se cargan. El núcleo no pudo decidir esto, porque algunas instalaciones pueden querer políticas diferentes (por ejemplo, específicas, estrictas, mls). Esto sucede al principio del proceso de arranque, pero lo omites cuando corres init=/bin/bash.
Michael Hampton
1
si no se carga una política, ¿por qué passwd"parece tener éxito"?
Andrew Savinykh
y si no tuvo éxito, ¿por qué falló el inicio de sesión con la contraseña anterior?
Carreras de ligereza en órbita el
2
@Jorge Helen: Tu explicación está casi completa. El punto son los archivos alterados por a passwdsaber /etc/passwdy /etc/shadow. Si se ejecuta passwdsin una política cargada, no se ejecuta en el contexto de selinux adecuado y los archivos alterados terminan con un contexto de selinux diferente. Al arrancar con selinux habilitado y las políticas activas, la verificación de contraseña falla debido a un contexto de archivo inapropiado y no debido a un wrong passworderror. Forzar a selinux a relacionar los contextos de archivo al tocar /.autorelabeltambién puede solucionar ese problema al cambiar las contraseñas sin una política cargada.
Hargut