Pregunta:
Tenemos una verificación de línea de base automatizada que genera una alerta si los permisos en /etc/shadow no están configurados en 000.
El personal que recibe estas alertas ha comenzado a cuestionar la cordura de 000, ya que root puede leer y escribir donde quiera (todos los archivos son automáticamente al menos 600 para root) pero root no puede ejecutar un archivo sin el conjunto de permisos de ejecución (no permiso automático de archivo 700 para root).
Establecer los permisos de /etc/shadow en 000 se encuentra en una serie de líneas de base, por ejemplo, los libros de jugadas de Ansible en el repositorio oficial de Red Hat GitHub (para PCI DSS, CJIS, NIST, CCE).
¿Hay una historia de origen detrás de por qué /etc/shadow debería ser 000 y no, por ejemplo, la funcionalidad aparentemente idéntica a 600? ¿O mis suposiciones son incorrectas sobre cuán restrictivo / permisivo es Linux para el usuario root?
Respuesta:
La idea detrás de configurar los permisos de /etc/shadow en 000 es proteger ese archivo para que los demonios no accedan a él, incluso cuando se ejecuta como root, asegurándose de que el acceso esté controlado por la capacidad DAC_OVERRIDE . Desde Fedora 12 y RHEL 6, los sistemas basados en Fedora ejecutan demonios sin DAC_OVERRIDE , pero otorgan DAC_OVERRIDE a las sesiones de inicio de sesión del administrador (para que el cambio sea invisible para los administradores).
Consulte las capacidades de proceso inferiores para obtener más detalles.
Esto se basa en el hecho de que 600 y 000 permisos no son funcionalmente idénticos: 600 otorga lectura y escritura al propietario del archivo, mientras que 000 solo otorga acceso a procesos con la capacidad DAC_OVERRIDE . Tradicionalmente, ejecutar como root siempre otorgaba DAC_OVERRIDE , pero ese no tiene por qué ser el caso.
(SELinux también se puede usar para limitar las habilidades de root, pero eso no es lo que está involucrado aquí. /etc/shadow tiene su propio contexto SELinux, proporcionando controles de acceso adicionales).