
Tengo un usuario $USER
que es una cuenta de usuario del sistema con un archivo de usuarios autorizados. Cuando tengo SELinux habilitado, no puedo ingresar al servidor mediante ssh usando la clave pública. Si puedo setenabled 0
, $USER
ahora puedo iniciar sesión.
¿Qué bool/política de SELinux debo cambiar para corregir este comportamiento sin deshabilitar SELinux por completo?
Vale la pena señalar que $USER
puedo iniciar sesión con una contraseña bajo esta configuración predeterminada de SELinux. Agradecería tener alguna idea de lo que está sucediendo aquí y por qué SELinux no está bloqueando eso. (Deshabilitaré la autenticación de contraseña por completo después de que esto se resuelva, por lo que es mejor saber esta pregunta)
Respuesta1
Suponiendo que los permisos del sistema de archivos sean correctos en ~/.ssh/*, luego verifique la salida de
sealert -a /var/log/audit/audit.log
Debería haber una pista en una entrada AVC allí. Lo más probable es que la solución se reduzca a ejecutar:
restorecon -R -v ~/.ssh
Respuesta2
Si sealert
falta en un sistema, como ocurría en un sistema que encontré recientemente, también existe la posibilidad de audit2allow
:
$ sudo audit2allow -w -a
type=AVC msg=audit(1548909218.552:1037): avc: denied { read } for pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
Desglosando el AVC:
avc: denied { read } for pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556
"sshd" was denied read on a file resource named "authorized_keys".
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
SELinux context of the sshd process that attempted the denied action.
tcontext=system_u:object_r:admin_home_t:s0 tclass=file
SELinux context of the authorized_keys file.
Aunque audit2allow no indicó de manera concisa cómo solucionar el problema, al observar scontext
y tcontext
, el scontext
valor indica el contexto necesario mientras tcontext
muestra el contexto insatisfactorio del archivo "authorized_keys".
En este caso, restorecon -R -v ~/.ssh
por sí solo no funcionó, pero aplicando el contexto deseado sí:
$ sudo semanage fcontext --add -t ssh_home_t "/path/to/my/.ssh(/.*)?"; \
$ sudo restorecon -FRv /path/to/my/.ssh
Según sea necesario, cambie los nombres de los recursos y/o el contexto según lo que se ve en el AVC. Los detalles precisos en esta respuesta se construyeron para resolver un problema relacionado con las "claves_autorizadas", pero una solución podría seguir este modelo incluso si se indica un archivo o contexto diferente en el AVC producido por sealert
o audit2allow
.