The Impact of DAC Overlays

Explain how traditional user and group permissions interact with MAC policies.

In this lesson, you will learn how Discretionary Access Control (DAC) acts as the primary gatekeeper before Mandatory Access Control (MAC) policies are even evaluated by the kernel.

The Two-Layer Security Architecture

In a modern hardened Linux system, access control is not a single check, but a hierarchy. Think of it as a bouncer at a club (DAC) followed by a metal detector (MAC).

DAC is the traditional permission model based on User IDs (UIDs), Group IDs (GIDs), and the rwxrwxrwx bits. MAC—whether implemented via SELinux or AppArmor—is the "overlay" that enforces a stricter, security-policy-defined logic. The critical rule is that MAC policies cannot grant access that DAC has already denied.

Why DAC is the First Barrier

When a process attempts to access a file, the kernel performs a sequential validation:

DAC Check: Does the process have the correct ownership or permission bits? If the permission is denied here, the kernel returns an EACCES error immediately. The MAC system is never even consulted.
MAC Check: If (and only if) the DAC check passes, the kernel then checks if the security context or profile permits the action.

Even if you configure a highly permissive MAC policy that allows httpd to read a sensitive file, it will fail if the file permissions are set to 600 and owned by a different user. The DAC layer effectively "overlays" the MAC policy, acting as a restrictive floor.

A Practical Example

Imagine you want to allow a web server to access a configuration file. You define an AppArmor profile allowing it, but you forget to update the file permissions:

# File permissions
-rw------- 1 root root /etc/myapp/config.yaml

# The process runs as user 'www-data'
# Even with a permissive MAC policy, the result is:
$ cat /etc/myapp/config.yaml
cat: /etc/myapp/config.yaml: Permission denied

In this scenario, the MAC system sees the request, but the kernel’s DAC check fails first because the user www-data does not have read access to a file owned by root. DAC acts as a "hard limit." Your MAC policies define who can, but DAC dictates who is allowed to try.

Key Takeaway: DAC is the mandatory first filter; if traditional user permissions deny an operation, the kernel blocks it before the MAC policy is ever reached.