Cuando un proceso realiza una operación en un archivo, el kernel de Linux realiza la verificación en el siguiente orden:
-
Control de acceso discrecional (DAC) o control de acceso dictado por el usuario. Esto incluye comprobaciones de permisos de estilo UNIX clásico y listas de control de acceso (ACL) POSIX. Las comprobaciones clásicas de UNIX comparan el UID y el GID del proceso actual con el UID y el GID del archivo al que se accede con respecto a los modos que se han establecido (lectura/escritura/ejecución). La lista de control de acceso amplía las comprobaciones clásicas de UNIX para permitir más opciones con respecto al control de permisos.
-
Control de acceso obligatorio (MAC) o control de acceso basado en políticas. Esto se implementa utilizando módulos de seguridad de Linux (LSM), que ya no son módulos reales (solían serlo, pero se eliminó). Permiten comprobaciones adicionales basadas en otros modelos además de las comprobaciones de seguridad clásicas de estilo UNIX. Todos esos modelos se basan en una política que describe qué tipo de operaciones se permiten para qué proceso y en qué contexto.
Aquí hay un ejemplo de acceso a inodos (que incluye acceso a archivos) para respaldar mi respuesta con enlaces a una referencia cruzada de Linux en línea. El "function_name (nombre de archivo:línea)" proporcionados son para la versión 3.14 del kernel de Linux.
La función inode_permission (fs/namei.c:449) primero verifica el permiso de lectura en el propio sistema de archivos (sb_permission en fs/namei.c:425), luego llama a __inode_permission (fs/namei.c:394) para verificar los permisos de lectura/escritura/ejecución y POSIX ACL en un inodo en do_inode_permission (fs/namei.c:368) (DAC) y luego permisos relacionados con LSM (MAC) en security_inode_permission (seguridad/seguridad.c:550).
Solo había uno excepción a esta orden (DAC luego MAC):fue para las comprobaciones mmap. Pero esto se solucionó en la versión 3.15 del kernel de Linux (compromiso relevante).
DAC ==Discretionary Access Control , http://en.wikipedia.org/wiki/Discretionary_access_control
MAC ==Mandatory Access Control , http://en.wikipedia.org/wiki/Mandatory_access_control
ACL ==Access Control List , http://en.wikipedia.org/wiki/Access_control_list
El ACL especifica los controles que se aplicarán por el método de control, DAC o MAC . MAC es explícito, controlado centralmente y no permite a los usuarios otorgar autoridad a un objeto a menos que tengan permisos explícitos para hacerlo, mientras que DAC permite a los usuarios otorgar acceso a otros usuarios a los objetos a los que pueden acceder.
MAC ACL Los s siempre se aplicarán primero a una solicitud y, si se deniega el acceso, se detiene el procesamiento. Si se permite el acceso, entonces el DAC ACL Se aplican correos electrónicos y, de nuevo, si se deniega el acceso, se detiene el procesamiento. Solo si ambos MAC otorgan acceso y DAC ACL s puede el usuario acceder al objeto que solicitó.
SELinux es un MAC implementación para Linux (hay otros), mientras que el tradicional rwx permisos de archivo, combinados con el usuario propietario y el grupo forman el DAC completo ACL . El SELinux 'política' es esencialmente el MAC ACL .
Lamento las objeciones, pero creo que algunas de las respuestas aquí podrían ser incorrecto Directamente desde http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html de Fedora:
Las reglas de política de SELinux se verifican después de las reglas de DAC. Las reglas de política de SELinux no se utilizan si las reglas DAC niegan el acceso primero.