Week 17 - Discretionary and Mandatory Access Control¶

17.1 Conceptual Core¶

DAC-discretionary access control-the classic rwx permissions plus POSIX ACLs (getfacl/setfacl). The owner decides who can access.
MAC-mandatory access control-the kernel decides, based on a policy administered separately from file ownership. Two implementations dominate Linux:
SELinux (RHEL family, default-enforcing). Type-enforcement-based. Powerful, complex.
AppArmor (Debian/Ubuntu/SUSE family). Path-based. Simpler, less expressive.
Both are LSMs (Linux Security Modules); only one is typically active per system.

17.2 Mechanical Detail¶

SELinux triple: <user>:<role>:<type>:<level>. The type is the workhorse; rules express "type X may do operation Y on type Z."
getenforce, setenforce 0|1, audit2allow, semanage, restorecon, chcon. Memorize these six.
ausearch -m AVC -ts recent for SELinux denials. audit2allow -a -M mymodule to draft a policy module from observed denials. Production discipline: never setenforce 0 to unblock; capture denials, build a policy, ship it.
AppArmor: profiles in /etc/apparmor.d/. Generate with aa-genprof, refine with aa-logprof. Modes: enforce, complain (logs but allows). aa-status shows active profiles.

17.3 Lab-"MAC for an Echo Service"¶

Take week 1's echo service. Author: 1. An SELinux type-enforcement module that allows it to bind its socket and read its config but nothing else. 2. An equivalent AppArmor profile. Verify with deliberate violations (try to read /etc/shadow)-both should deny and audit.

17.4 Hardening Drill¶

Survey your distro: which LSM is active? Read its policy for one well-known service (httpd on RHEL, nginx on Ubuntu) and explain the constraint set.

17.5 Performance Tuning Slice¶

Measure SELinux/AppArmor overhead with perf stat on a syscall-heavy workload-typically <2%.