Linux – What roles do DAC (file permissions), ACL and MAC (SELinux) play in Linux file security

acllinuxpermissionsselinux

I need some clarification/confirmation/elaboration on the different roles DAC, ACL and MAC play in Linux file security.

After some research from the documentation, this is my understanding of the stack:

  1. SELinux must allow you access to the file object.
  2. If the file's ACLs (e.g., setfacl, getfacl for an ACL mount) explicitly allows/denies access to the object, then no further processing is required.
  3. Otherwise, it is up to the file's permissions (rwxrwxrwx DAC model).

Am I missing something? Are there situations where this is not the case?

Best Answer

When a process performs an operation to a file, the Linux kernel performs the check in the following order:

  1. Discretionary Access Control (DAC) or user dictated access control. This includes both classic UNIX style permission checks and POSIX Access Control Lists (ACL). Classical UNIX checks compare the current process UID and GID versus the UID and GID of the file being accessed with regards to which modes have been set (Read/Write/eXecute). Access Control List extends classic UNIX checks to allow more options regarding permission control.

  2. Mandatory Access Control (MAC) or policy based access control. This is implemented using Linux Security Modules (LSM) which are not real modules anymore (they used to be but it was dropped). They enable additionnal checks based on other models than the classical UNIX style security checks. All of those models are based on a policy describing what kind of opeartions are allowed for which process in which context.

Here is an example for inodes access (which includes file access) to back my answer with links to an online Linux Cross Reference. The "function_name (filename:line)" given are for the 3.14 version of the Linux kernel.

The function inode_permission (fs/namei.c:449) first checks for read permission on the filesystem itself (sb_permission in fs/namei.c:425), then calls __inode_permission (fs/namei.c:394) to check for read/write/execute permissions and POSIX ACL on an inode in do_inode_permission (fs/namei.c:368) (DAC) and then LSM-related permissions (MAC) in security_inode_permission (security/security.c:550).

There was only one exception to this order (DAC then MAC): it was for the mmap checks. But this has been fixed in the 3.15 version of the Linux kernel (relevant commit).

Related Question