Estaba experimentando y aprendiendo SELinux en Alma Linux 9.2. La intención era crear una aplicación flask que tenga una vulnerabilidad de inclusión de archivos y mostrar cómo SELinux puede prevenir la vulnerabilidad para proteger ciertos archivos que no deberían ser accesibles para un atacante incluso si la aplicación flask estuviera comprometida. Para probar esto, creé un archivo de texto en el directorio de inicio de un usuario e intenté acceder a él a través de la aplicación flask y se aplicó SELinux. SELinux lo bloqueó. Hasta ahora, todo bien. Luego intenté leer el /etc/passwdarchivo a través de la aplicación flask y lo permitió. ¡No estoy seguro por qué! Pensé que /etc/passwdera lo suficientemente sensible como para que SELinux bloqueara el acceso no autorizado. Aquí está el resultado ls -Zde los dos archivos.
system_u:object_r:passwd_file_t:s0 /etc/passwd
unconfined_u:object_r:user_home_t:s0 /home/vagrant/test.txt
No estoy seguro de si este es el comportamiento previsto.
Respuesta1
Para repetir mi comentario inicial:
- Por norma general
/etc/passwdno se considera sensible. La información allí es necesaria para que las aplicaciones busquen números UID y muestren nombres de usuario amigables para los humanos, por ejemplo.
Una segunda consideración:
- A menos que cree un contexto SELinux personalizado para su aplicación/demonio personalizado, no se ejecutará con ninguna protección/restricción específica. (Y efectivamente, sólo los privilegios del sistema de archivos convencionales niegan el acceso).
Puede verificar el contexto SELinux actual de un demonio en ejecución con la -Zopción en ps. Lo que veas dependerá un poco de cómo inicies tu demonio, pero porejemplo:
ps -efZ | grep mydaemon
system_u:system_r:unconfined_service_t:s0 root 4117 1 0 16:56 ? 00:00:00 /usr/local/bin/mydaemon
muestra unconfined_service_ty eso significa: sin restricciones, sin política SELinux.
ElManual de Red Hat SELinuxproporciona una introducción rápida sobre cómo crear una política SELinux personalizada:
- Generar una política personalizada:
sepolicy generate --init /usr/local/bin/mydaemon - Reconstruya la política del sistema con el nuevo módulo de política usando el script de configuración:
cd /home/example.user/mysepol ; ./mydaemon.sh - Vuelva a etiquetar la parte correspondiente del sistema de archivos usando el comando recoverycon:
restorecon -v /usr/local/bin/mydaemon /usr/lib/systemd/system - Reinicie el demonio y verifique que ahora se ejecute confinado en SELinux.
- Ahora debería ver denegaciones/errores de SELinux.