¿Qué roles juegan DAC (permisos de archivo), ACL y MAC (SELinux) en la seguridad de los archivos de Linux?

Necesito alguna aclaración / confirmación / elaboración sobre los diferentes roles que juegan DAC, ACL y MAC en la seguridad de los archivos de Linux.

Después de un poco de investigación de la documentación, esta es mi comprensión de la pila:

1. SELinux debe permitirle acceder al objeto de archivo.
2. Si ACL del archivo (por ejemplo, setfacl, getfaclpara un montaje ACL) permite explícitamente / deniega el acceso al objeto, entonces no se requiere un procesamiento adicional.
3. De lo contrario, depende de los permisos del archivo (modelo rwxrwxrwx DAC).

¿Me estoy perdiendo de algo? ¿Hay situaciones en las que este no es el caso?

Cuando un proceso realiza una operación en un archivo, el kernel de Linux realiza la verificación en el siguiente orden:

1. Control de acceso discrecional (DAC) o control de acceso dictado por el usuario. Esto incluye las comprobaciones de permisos de estilo UNIX clásico y las 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 qué modos se han configurado (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.

2. 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 ser pero se descartó). Permiten comprobaciones adicionales basadas en otros modelos distintos de las comprobaciones de seguridad de estilo UNIX clásico. 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 inodes (que incluye acceso a archivos) para respaldar mi respuesta con enlaces a una referencia cruzada de Linux en línea . Los " function_name(nombre de archivo: línea)" indicados 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_permissionen fs / namei.c: 425 ), luego llama__inode_permission ( fs / namei.c: 394 ) para verificar la lectura / escritura / ejecución permisos 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( security / security.c: 550 ).

Solo habia uno excepción a este orden (DAC luego MAC): fue para las comprobaciones de mmap. Pero esto se ha solucionado en la versión 3.15 del kernel de Linux ( confirmación 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

Los ACLEspecifica los controles que han de aplicarse por el método de control, DACo MAC. MACes 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 DACpermite a los usuarios otorgar a otros usuarios acceso a los objetos a los que pueden acceder.

MAC ACLs siempre se aplicará primero a una solicitud y, si se deniega el acceso, el procesamiento se detiene. Si se permite el acceso, entonces DAC ACLse aplican los s, y nuevamente si se niega el acceso, el procesamiento se detiene. Solo si el acceso es otorgado por ambosMAC y DAC ACLs, el usuario puede acceder al objeto que solicitó.

SELinuxes una MACimplementación para Linux (hay otros), mientras que los rwxpermisos de archivo tradicionales , combinados con el usuario propietario y el grupo forman el completo DAC ACL. La SELinux'política' es esencialmente la MAC ACL.

Perdón por objetar, pero creo que algunas de las respuestas aquí podrían ser incorrectas. 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 usan si las reglas de DAC niegan el acceso primero.