Implementing Mandatory Access Controls in Linux

Table of Contents

1. What is Mandatory Access Control (MAC)?
2. MAC vs. Discretionary Access Control (DAC): Key Differences
3. Linux MAC Frameworks
   • SELinux (Security-Enhanced Linux)
   • AppArmor (Application Armor)
4. Choosing Between SELinux and AppArmor
5. Best Practices for Implementing MAC
6. Troubleshooting Common MAC Issues
7. Conclusion
8. References

What is Mandatory Access Control (MAC)?

MAC is a security model where access to resources (files, processes, network ports) is controlled by system-wide policies enforced by the operating system kernel. Unlike DAC, where owners of resources set permissions, MAC policies are defined by system administrators and cannot be overridden by users or processes—even root.

Core Principles of MAC:

• Centralized Policy Enforcement: Policies are defined by administrators and enforced by the kernel.
• Least Privilege: Processes and users are granted only the access required to perform their tasks.
• Immutability: Policies cannot be modified by non-privileged users (or even root, in some cases).
• Granular Control: Policies can restrict access based on context (e.g., process type, user role, data sensitivity level).

MAC vs. Discretionary Access Control (DAC): Key Differences

To understand MAC’s value, let’s contrast it with DAC, Linux’s default access control model:

Example: With DAC, a user could accidentally set chmod 777 on a sensitive file, exposing it to all users. With MAC, even if DAC permissions are overly permissive, the MAC policy would block unauthorized access.

Linux MAC Frameworks

Linux offers several MAC implementations, each with unique design philosophies. The most widely adopted are SELinux and AppArmor.

SELinux (Security-Enhanced Linux)

Developed by the NSA and later integrated into the Linux kernel (2.6.0+), SELinux is a powerful, flexible MAC framework based on Type Enforcement (TE), Role-Based Access Control (RBAC), and Multi-Level Security (MLS).

Key Concepts:

• Type Enforcement (TE): The foundation of SELinux. Every process and file is assigned a “type” (e.g., httpd_t for Apache, var_t for /var files). Rules define which types can access others (e.g., httpd_t → httpd_sys_content_t).
• Role-Based Access Control (RBAC): Users are assigned roles (e.g., sysadm_r, user_r), and roles are granted permissions to execute types. Prevents users from running unauthorized processes.
• Multi-Level Security (MLS): Enforces confidentiality by labeling data with sensitivity levels (e.g., “Top Secret,” “Secret”) and users with clearance levels. Prevents lower-clearance users from accessing higher-level data.

SELinux Modes:

SELinux operates in three modes, configurable via /etc/selinux/config or setenforce:

• Enforcing: Actively enforces policies and blocks unauthorized access.
• Permissive: Logs policy violations but does not block access (useful for testing).
• Disabled: SELinux is turned off.

Implementing SELinux: A Step-by-Step Guide

1. Check SELinux Status

Most modern distributions (RHEL, Fedora, CentOS) enable SELinux by default. Verify its status:

sestatus  
# Output example:  
# SELinux status:                 enabled  
# SELinuxfs mount:                /sys/fs/selinux  
# SELinux root directory:         /etc/selinux  
# Loaded policy name:             targeted  
# Current mode:                   enforcing  
# Mode from config file:          enforcing  
# Policy MLS status:              enabled  
# Policy deny_unknown status:     allowed  
# Memory protection checking:     actual (secure)  
# Max kernel policy version:      33  

2. Install SELinux Utilities

If missing, install SELinux management tools:

# RHEL/CentOS/Fedora  
sudo dnf install policycoreutils policycoreutils-python-utils selinux-policy selinux-policy-targeted auditd  

# Enable auditd (logs SELinux denials)  
sudo systemctl enable --now auditd  

3. Configure SELinux Modes

Edit /etc/selinux/config to set the default mode (requires reboot):

SELINUX=enforcing   # or permissive/disabled  
SELINUXTYPE=targeted  # "targeted" (most common) or "strict" (all processes)  

To temporarily switch modes (no reboot):

sudo setenforce 0  # Permissive mode  
sudo setenforce 1  # Enforcing mode  

4. Managing SELinux Policies

SELinux policies are stored in /etc/selinux/targeted/policy/. For most users, the targeted policy (which protects critical services like Apache, SSH, and MySQL) is sufficient.

• View File/Process Contexts:
  Every file and process has an SELinux “context” (user:role:type:level). Use ls -Z (files) or ps -Z (processes) to view contexts:

  ls -Z /var/www/html/index.html  
  # Output: -rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html  

• Modify Contexts: Use chcon (temporary) or semanage fcontext (permanent) to change file types:

  # Permanently set /srv/web to httpd_sys_content_t  
  sudo semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"  
  sudo restorecon -Rv /srv/web  # Apply the change  

• Generate Custom Policies: Use audit2allow to create policies from denial logs. For example, if Apache is blocked from accessing a custom log directory:

  # Check audit logs for denials  
  sudo grep httpd /var/log/audit/audit.log | audit2allow -M my-httpd-policy  
  # Install the policy  
  sudo semodule -i my-httpd-policy.pp  

AppArmor (Application Armor)

Developed by Novell and adopted by Ubuntu, SUSE, and Debian, AppArmor is a simpler, path-based MAC framework designed for ease of use. Unlike SELinux’s type-based rules, AppArmor uses pathnames to define access controls for processes.

Key Concepts:

• Profiles: Text files defining allowed/disallowed actions for a process (e.g., /etc/apparmor.d/usr.sbin.nginx for Nginx). Profiles can be in enforcing (block violations) or complain (log violations) mode.
• Path-Based Rules: Rules specify which files/directories a process can access (e.g., /var/www/html/** r, allows read access to /var/www/html).
• Capabilities: Restrict Linux capabilities (e.g., CAP_NET_BIND_SERVICE for binding to ports <1024) to limit process privileges.

Implementing AppArmor

1. Check AppArmor Status

AppArmor is enabled by default on Ubuntu/Debian. Verify status with:

sudo aa-status  
# Output example:  
# apparmor module is loaded.  
# 12 profiles are loaded.  
# 10 profiles are in enforce mode.  
#   /usr/sbin/nginx  
#   ...  

2. Install Tools

Install AppArmor utilities for profile management:

# Ubuntu/Debian  
sudo apt install apparmor-utils  

3. Manage Profiles

• View Profile Modes: Use aa-status or check individual profiles:

  sudo aa-status /usr/sbin/nginx  

• Switch Modes: Use aa-complain or aa-enforce to toggle a profile’s mode:

  sudo aa-complain /usr/sbin/nginx  # Switch to complain mode  

• Generate a Profile: Use aa-genprof to create a profile interactively. For example, for a custom Node.js app:

  sudo aa-genprof /usr/bin/node  
  # Follow prompts to allow/deny access as the app runs  

• Edit Profiles: Manually edit profiles in /etc/apparmor.d/. For example, restrict Nginx to read-only access for /var/www/html and block /tmp:

  sudo nano /etc/apparmor.d/usr.sbin.nginx  

  Add rules:

  /var/www/html/** r,  # Allow read access  
  /tmp/ deny,          # Block /tmp access  

  Reload the profile:

  sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx  

Choosing Between SELinux and AppArmor

Selecting a MAC framework depends on your use case, distribution, and complexity tolerance:

Recommendation: For enterprise servers or compliance (e.g., PCI-DSS), use SELinux for its granularity. For desktops or small servers, AppArmor’s simplicity may be preferable.

Best Practices for Implementing MAC

1. Start in Permissive/Complain Mode: Test policies without blocking access. Monitor logs to identify and resolve false positives before enforcing.
2. Use Default Policies: Leverage distribution-provided profiles (e.g., SELinux’s targeted policy, AppArmor’s prebuilt profiles) before customizing.
3. Enforce Least Privilege: Restrict processes to only the access they need (e.g., Apache shouldn’t write to /tmp unless required).
4. Monitor Logs: Use auditd (SELinux) or aa-logprof (AppArmor) to track denials and refine policies.
5. Version Control Policies: Store custom policies in Git to track changes and roll back if needed.
6. Test in Staging: Validate policies in a non-production environment to avoid breaking critical services.

Troubleshooting Common MAC Issues

SELinux Denials

• Symptom: A service fails to start or access resources.
• Fix:
  1. Check audit logs: sudo sealert -a /var/log/audit/audit.log (SELinux Alert Browser).
  2. Use audit2allow to generate a policy snippet for the denial.
  3. Verify file contexts with ls -Z and correct them with restorecon.

AppArmor Denials

• Symptom: A process is blocked from accessing files.
• Fix:
  1. Check logs: sudo grep "apparmor=DENIED" /var/log/syslog.
  2. Use aa-logprof to interactively update the profile based on denials.
  3. Ensure paths in the profile match the actual file system (e.g., /srv/www vs. /var/www).

Conclusion

Mandatory Access Control is a critical layer in Linux security, addressing DAC’s limitations by enforcing strict, policy-driven access controls. Whether you choose SELinux for its enterprise-grade flexibility or AppArmor for simplicity, implementing MAC significantly reduces the risk of data breaches, privilege escalation, and compliance violations.

By following best practices—starting in permissive mode, leveraging default policies, and monitoring logs—you can deploy MAC effectively without disrupting system functionality. As security threats evolve, MAC remains an indispensable tool for securing Linux systems in today’s zero-trust landscape.

References

• SELinux Project Wiki
• AppArmor Documentation
• Red Hat Enterprise Linux: SELinux User’s and Administrator’s Guide
• Ubuntu: AppArmor How-To
• Linux Kernel MAC Documentation
• Russell Coker’s SELinux by Example (Prentice Hall, 2006)