Table of Contents
Why Mandatory Access Control Exists
Traditional Unix permissions and ownership are discretionary: the owner of a file (or root) decides who can do what. If an application is compromised, it can usually do anything its user (or root) could do.
Mandatory Access Control (MAC) systems like SELinux and AppArmor add an extra, kernel‑enforced security layer:
- Policies are defined centrally by administrators, not by each application.
- Even if a process runs as root, its actions can be restricted.
- Access decisions use more context than just user/group/other.
On many enterprise or security‑focused distributions, SELinux or AppArmor is enabled by default.
This chapter gives you just enough to recognize both systems, understand what they do, and know where to look when they block something.
SELinux: The Basics
Security‑Enhanced Linux (SELinux) is a MAC system originally developed by the NSA and now widely used, especially in RHEL, CentOS Stream, Fedora, and Rocky/AlmaLinux.
Core Ideas
SELinux adds labels and policies on top of normal permissions:
- Labels (contexts): Every process and most objects (files, sockets, etc.) get a security context, e.g.:
system_u:system_r:httpd_t:s0
system_u:object_r:httpd_sys_content_t:s0
You’ll usually see the type field referenced most (e.g. httpd_t, ssh_t, httpd_sys_content_t).
- Policy rules: Define which types can access which types, and how (read, write, execute, bind to port, etc.).
- Decisions: When a process does something (open a file, bind a port), the kernel checks:
- Unix permissions (user/group/mode bits, ACLs)
- and SELinux policy
Access is only allowed if both agree.
Modes: Enforcing, Permissive, Disabled
You’ll commonly see SELinux in one of three modes:
- Enforcing: Policy is applied; disallowed actions are denied and logged.
- Permissive: Policy is not enforced, but violations are logged. Useful for debugging.
- Disabled: SELinux is turned off.
To check mode:
getenforce
# or
sestatus
Typical outputs: Enforcing, Permissive, or Disabled.
Switching temporarily (runtime only, requires root and SELinux not disabled):
setenforce 0 # Permissive
setenforce 1 # Enforcing
Permanent mode changes are done in SELinux config files (distribution‑specific; usually /etc/selinux/config), not covered in detail here.
Types of SELinux Policies (High Level)
Distributions ship with a policy that defines how SELinux behaves. Common types:
- Targeted policy (most common):
- Only specific, high‑risk services are confined (e.g.
httpd,sshd,named). - Regular user processes may be largely unaffected.
- MLS/Strict policies:
- Much more comprehensive and complex.
- Rare for beginners; typically used in high‑security environments.
For intermediate system administration, you will almost always deal with a targeted policy.
Common SELinux Tools You’ll Encounter
You don’t need to master them now, but recognize these names when you see them in documentation or troubleshooting guides:
sestatus– view SELinux status and mode.ls -Z– show SELinux security context (label) on files.ps -Z– show SELinux context of processes.chcon– change SELinux context temporarily (non‑persistent).semanage fcontext– manage persistent file context mappings.restorecon– apply default SELinux labels based on policy rules.
Example showing file labels:
ls -Z /var/www/html
-rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 index.htmlSELinux in the Real World: Simple Scenarios
These are typical patterns you may see when SELinux is involved.
Example: Web Server Cannot Read Content
Symptom: httpd (Apache) is running, permissions look fine, but content under a non‑standard directory isn’t served.
Quick checks:
- Verify SELinux context:
ls -Zd /srv/myweb- If the type is not
httpd_sys_content_t(or similar), SELinux may be blocking reads.
The usual pattern to fix this (conceptually):
- Define the right file context mapping with
semanage fcontext. - Apply it with
restorecon.
(Exact commands and deeper usage belong to troubleshooting‑focused material.)
Example: Denials in Logs
When SELinux denies something, it logs to:
- Audit logs (often
/var/log/audit/audit.log) - Sometimes
/var/log/messagesor the journal (journalctl)
You might see brief hints like:
SELinux is preventing /usr/sbin/httpd from read access on the file /srv/myweb/index.html.
Or a raw avc: denied line. Tools like sealert (when available) can interpret these messages and suggest policy or configuration changes.
AppArmor: The Basics
AppArmor is another MAC system, but with a different design philosophy. It’s used by Ubuntu, openSUSE, and some others.
Core Ideas
While SELinux is label‑based, AppArmor is primarily path‑based:
- Profiles are written per program (e.g.
/usr/sbin/sshd), not per file type. - A profile lists which files, capabilities, and network access that program is allowed or denied.
- The kernel enforces those rules based on the file paths a process tries to use.
Example conceptual rule (not full syntax):
- “
/usr/sbin/sshdcan read/etc/ssh/sshd_configbut cannot write/etc/shadow.”
Modes: Enforce and Complain
Each AppArmor profile can be in its own mode:
- Enforce mode:
- Rules are applied; disallowed actions are blocked and logged.
- Complain mode:
- Violations are logged but not blocked.
- Used to test and tune new or modified profiles.
AppArmor itself can be enabled or disabled at the system level (boot parameters, service state), but at the day‑to‑day level you often interact with profile modes.
On Ubuntu, typical tools:
aa-status– show which profiles are loaded and their modes.aa-enforce PROFILE– put a profile into enforce mode.aa-complain PROFILE– put a profile into complain mode.
AppArmor Profiles
Profiles are usually stored under:
/etc/apparmor.d/
You’ll see one file per confined application, such as:
/etc/apparmor.d/usr.sbin.mysqld/etc/apparmor.d/usr.sbin.apache2
Profiles:
- Are written in a relatively readable syntax.
- Can be shipped by packages, then customized by administrators.
- Are loaded and managed via AppArmor utilities (e.g.
apparmor_parser,systemctlfor the AppArmor service).
SELinux vs AppArmor: Conceptual Differences
For an intermediate admin, you mainly need to recognize:
- Where you’ll encounter each:
- SELinux: Default on many RHEL/Fedora‑family systems.
- AppArmor: Default on Ubuntu and openSUSE.
- How they think about access control:
- SELinux: Label‑based MAC. Policies apply to types (labels) on both processes and objects.
- AppArmor: Path‑based MAC. Policies are per program, using filesystem paths.
- Configuration style:
- SELinux: Central policy, types, booleans, file contexts.
- AppArmor: Per‑application profiles, easier to read for many admins.
You normally don’t run both at the same time on the same system; distributions standardize on one.
Typical Beginner‑Level Interactions
As a beginner/intermediate system administrator, the ways you’ll most often touch these systems are:
- Checking if they are causing a problem:
- SELinux:
getenforce/sestatus, look for AVC denials in logs. - AppArmor:
aa-status, check if a relevant profile is in enforce mode. - Temporarily relaxing them for diagnosis:
- SELinux: Temporarily switch to Permissive (not disabled) while you gather information, then switch back.
- AppArmor: Put a specific profile into complain mode while testing.
- Recognizing log messages:
- SELinux: Look for
avc: deniedandSELinux is preventing ...messages. - AppArmor: Look for mentions of
apparmor=orDENIEDin logs (e.g.journalctl). - Knowing they exist when reading documentation:
- Many service hardening or troubleshooting steps explicitly mention SELinux or AppArmor changes.
- When you follow a guide and something still doesn’t work, an active MAC system is often the missing piece.
When to Learn More
You don’t need to write policies or profiles at this stage, but it’s helpful to know:
- On RHEL/Fedora‑like systems, look for SELinux documentation and tools.
- On Ubuntu/openSUSE, look for AppArmor references.
- For more advanced security work, you’ll later explore:
- Adjusting SELinux booleans instead of turning SELinux off.
- Creating/adjusting AppArmor profiles for custom applications.
- Integrating MAC systems with other security measures (firewalls, user permissions, SSH configuration, etc.).
Knowing that SELinux and AppArmor are the kernel‑level policy engines that may allow or block actions even when file permissions look correct is the key takeaway at this stage.