MAC vs DAC - mandatory versus discretionary access control

Linux has two access control models: DAC (the standard file permissions) and MAC (mandatory access control, layered on top). MAC matters in production because DAC alone allows too much damage from compromised services.

DAC: discretionary access control

DAC is the standard Linux model:

• Files have an owner and a mode (rwx for user/group/other).
• The owner can change the mode.
• A process running as a user has all of that user’s permissions.

This is “discretionary” because the user can choose who has access. If a web server is compromised and runs as www-data, the attacker has all of www-data’s permissions - including read access to anything world-readable.

MAC: mandatory access control

MAC adds an extra layer of restrictions on top of DAC. Even if DAC says a process can access a file, MAC can deny it.

• SELinux (Red Hat): label-based MAC. Every file and process has a context. Policy defines allowed transitions.
• AppArmor (Debian, Ubuntu): path-based MAC. Profiles define what each binary can do (read, write, network, capability).

MAC is “mandatory” because the policy is enforced by the kernel and cannot be bypassed by the user.

Why MAC matters

Consider a web application compromised through a vulnerable plugin:

• With DAC only: the attacker can read /etc/passwd, /etc/shadow (if permissions are wrong), the application’s database credentials, etc.
• With MAC (SELinux targeted policy or AppArmor profile): the web server’s process can only do what the policy allows. Reading /etc/shadow is denied even if DAC would permit it.

The compromised service is constrained to the minimum needed for its job.

What MAC enforces

• File access: which files a process can read, write, execute.
• Network access: which ports a process can bind or connect to.
• Capabilities: which Linux capabilities a process can acquire.
• Signals: which signals a process can send.
• Resource limits: some MAC systems enforce rlimits.

Trade-offs

MAC adds:

• Security: defence in depth. A compromised service is constrained.
• Visibility: every action is logged with the MAC context.

MAC also adds:

• Complexity: writing policies is a skill. A wrong policy can deny legitimate access.
• Operational cost: every deployment must be tested against the policy.

For most production hosts, MAC is the right choice with the default policy. For development or tightly-controlled workloads, MAC may be disabled.

Knowledge check