LPIC-3 Security: Access Control

Access control demands precision: you must understand how DAC, POSIX ACLs, PAM, sudo, and mandatory access control (SELinux, AppArmor) interact, and fix denials at the correct layer.

Core rules

• DAC: owner/group/other bits plus umask; setgid on directories inherits the group, the sticky bit on /tmp restricts deletion.
• POSIX ACLs extend DAC: setfacl -m u:alice:rw file, setfacl -d -m g:devs:rx dir for defaults. The mask caps effective rights; getfacl shows + and effective: entries.
• PAM stack in /etc/pam.d/: types auth, account, password, session; controls required, requisite, sufficient, optional. Order matters - a requisite failure halts the stack, a sufficient success can short-circuit it.
• SELinux: getenforce/setenforce, persistent mode in /etc/selinux/config. Contexts are user:role:type:level. Fix files permanently with semanage fcontext -a -t httpd_sys_content_t '/srv/www(/.*)?' followed by restorecon -Rv /srv/www; chcon is temporary. Booleans via setsebool -P. Diagnose with ausearch -m AVC -ts recent or sealert.
• AppArmor: path-based profiles in /etc/apparmor.d, inspected with aa-status, relaxed with aa-complain for troubleshooting.
• sudo: visudo -c, drop-ins in /etc/sudoers.d, syntax user host=(runas) command; the last matching rule wins.

Worked example

Apache returns 403 for /srv/www although permissions are 755. ls -Z shows default_t instead of httpd_sys_content_t. Correct action: add the fcontext rule, run restorecon -Rv, retest. Reasoning: SELinux type enforcement blocked access, not DAC - chmod 777 or setenforce 0 would hide the fault and weaken the host.

Traps

Editing the wrong PAM file for the distribution; placing session requirements in the auth stack; assuming chcon survives a relabel; disabling SELinux instead of labelling; forgetting -P on setsebool; overlooking sudoers ordering.