Access Control: ACLs, sudo & PAM

Intermediate40 min6 steps

What you'll learn

Grant fine-grained file access with POSIX ACLs (getfacl/setfacl)
Delegate admin rights safely with sudo and least privilege
Understand how PAM authenticates logins and enforces lockout/complexity
Replace risky SUID with file capabilities

The layers of access control
See how authentication, authorization, and auditing fit together.
"Access control" is really three questions, asked in order:
1. Authentication — who are you? (passwords, keys — enforced by PAM).
2. Authorization — what may you do? (file permissions + ACLs for files; sudo for admin actions).
3. Auditing — what did you do? (logs, auditd).
Standard permissions (rwx for owner/group/others) handle most files, but they're coarse — three buckets only. When you need to grant one extra person access, or hand a user one admin command without the root password, you reach for the finer tools in this lesson: ACLs, sudo, and the PAM framework underneath login itself.
Why it matters
The guiding principle throughout is least privilege: grant the minimum access that works, scoped and logged — never the master key when a single door will do. Every tool here exists to make "just enough" access possible. When you catch yourself reaching for chmod 777, adding someone to wheel, or setting a SUID bit, pause: there is almost always a narrower grant — an ACL entry, one sudo command, a single capability — that does the job without widening the blast radius.
POSIX ACLs — beyond owner/group/others
Grant a specific user or group access without changing the base permissions.
Standard permissions give you exactly three subjects: the owner, one group, and everyone else. But what if alice owns a report, the finance group can read it, and you also need to give just bob write access — without adding bob to finance or opening it to others? That's an ACL (Access Control List): a per-file guest list of extra user/group grants layered on top of the normal bits.
Example — not runnable on your lab box
```
$ setfacl -m u:bob:rw report.txt; getfacl report.txt; ls -l report.txt
```
```
# file: report.txt
# owner: alice
# group: finance
user::rw-
user:bob:rw-
group::r--
mask::rw-
other::r--

-rw-rw-r--+ 1 alice finance 0 report.txt
```
-m u:bob:rw
Modify/add: grant user bob read+write.
-m g:auditors:r
Same for a group (g:).
-x u:bob
Remove bob's ACL entry.
-b
Strip ALL ACLs, back to plain permissions.
setfacl -m adds the entry; getfacl shows the full list. The giveaway in ls -l is the trailing `+` on -rw-rw-r--+ — it means "this file has ACLs, the standard bits don't tell the whole story." The `mask` line is the ceiling on what named users/groups can get; if effective access looks wrong, check the mask.
Default ACLs make new files inherit
A default ACL on a directory (setfacl -m d:u:bob:rw /project) is inherited by files created inside it — the ACL equivalent of SGID for group inheritance. Great for shared project trees where everything new should be reachable by a team member.
The mask gotcha: why your grant looks half-applied
The mask:: line in getfacl is a ceiling on every named user and group entry (but not the owner or others). If you grant u:bob:rw but the mask is r--, bob's effective access is only r — getfacl even flags it with #effective:r-- next to his line. This bites people constantly: they add write access, it silently doesn't take, and nothing errors. The cause is usually a later chmod on the file, which recalculates the mask down. Fix it by re-widening the mask (setfacl -m m::rw file) or by re-applying the entry. Rule of thumb: after any chmod on an ACL'd file, re-check getfacl for #effective warnings.
Check yourself
Which command grants user bob read/write to a file, beyond the standard owner/group/other permissions?
sudo — delegate admin, least privilege
Grant specific root powers without the root password.
sudo lets a user run commands as root (or another user) using their own password, with every command logged. The policy lives in /etc/sudoers, and each rule reads:
who host=(run-as) commands — e.g. alice ALL=(ALL) ALL is "alice, anywhere, as anyone, any command."
```
$ sudo visudo -f /etc/sudoers.d/webadmins
```
```
%webadmins ALL=(ALL) /usr/bin/systemctl * nginx
carol      ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart httpd
```
%webadmins
A group rule (the % prefix) — role-based, the scalable way.
/usr/bin/systemctl * nginx
Restrict to specific commands, not ALL.
NOPASSWD:
Skip the password for these commands (use sparingly).
Least privilege in practice: grant a group just the commands it needs, not blanket ALL. Edit only with `visudo` (it syntax-checks before saving) and prefer drop-ins in /etc/sudoers.d/. A user checks their own grants with sudo -l.
Editing /etc/sudoers by hand can lock everyone out
A syntax error in sudoers disables all sudo — and you need sudo to fix it. visudo refuses to save a broken file, which is the whole point. Same for /etc/sudoers.d/* — edit with visudo -f. (Keep a root shell open while testing sudo changes.)
Check yourself
What is the only safe way to edit the sudoers policy?
PAM — the authentication framework
Understand what decides whether a login succeeds.
When you log in, run sudo, or ssh in, the decision isn't hard-coded in each program — it's delegated to PAM (Pluggable Authentication Modules). Each service has a config in /etc/pam.d/ that stacks modules like a series of checkpoints. A line is type control module:
- type: auth (verify identity) · account (is the account allowed now?) · password (changing it) · session (set up/tear down).
- control: required (must pass, keep going) · requisite (must pass, stop now if not) · sufficient (pass = done) · optional.
Example — not runnable on your lab box
```
$ grep -E 'faillock|pwquality' /etc/pam.d/system-auth /etc/security/pwquality.conf
```
```
auth required pam_faillock.so preauth deny=5 unlock_time=900
password requisite pam_pwquality.so retry=3
minlen = 12
dcredit = -1
```
Two PAM modules you'll meet on the exam: `pam_faillock` locks an account after N failed logins (deny=5, auto-unlock after unlock_time); `pam_pwquality` enforces complexity (minlen, dcredit=-1 = at least one digit). Check/clear lockouts with faillock --user alice and faillock --user alice --reset.
Warning
A wrong edit to /etc/pam.d/system-auth can lock you out of the whole system. Use the distro tool (`authselect` on RHEL) instead of hand-editing, keep a root session open while testing, and change one thing at a time.
Check yourself
Which PAM module locks an account after repeated failed login attempts?
Harden privilege: SUID review and capabilities
Audit root-power binaries and prefer capabilities to SUID.
A SUID-root binary runs as root for anyone who executes it — necessary for a few tools like passwd (which must edit /etc/shadow on your behalf), but a privilege-escalation magnet if misused. Here's the danger made concrete: if a SUID-root program can be made to run another command — an editor that shells out, a tool with a --exec flag, a script that calls a binary by relative path — the attacker inherits root through it. Whole classes of Linux privilege escalation are just 'find a SUID binary that does slightly more than it should.' That's why the audit below matters: every SUID bit is attack surface you're choosing to keep. The modern, least-privilege alternative is a capability: hand a program just the one kernel power it needs instead of the full root toolbox.
```
$ find / -perm -4000 -type f 2>/dev/null; getcap /usr/bin/ping; sudo setcap cap_net_raw+ep /usr/bin/myping
```
```
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/su
/usr/bin/mount
/usr/bin/ping cap_net_raw=ep
```
find / -perm -4000
List every SUID file — the audit step on the security exams.
getcap FILE
Show a file's capabilities.
setcap cap_net_raw+ep
Grant just the raw-socket power (what ping needs) — no SUID.
Audit SUID binaries regularly and remove the bit where it isn't needed (chmod u-s). Where a tool only needs one privilege, a capability (cap_net_raw for ICMP, cap_net_bind_service to bind <1024) replaces SUID — the program gets that single power and nothing more. This is why modern ping often has cap_net_raw instead of being SUID-root.
Tip
Audit the access-control config itself with auditd: auditctl -w /etc/sudoers -p wa -k sudoers and -w /etc/pam.d/ -p wa log every change to your sudo/PAM policy — the "what did you do?" third layer.
Practice in your live terminal
Do it, don't just read it — these run on the real sandbox to your right.
You have a real shell. Set an ACL, check your sudo grants, and audit privilege — only the ACL step changes anything (a temp file you create).
```
$ touch /tmp/acltest; setfacl -m u:nobody:rw /tmp/acltest; getfacl /tmp/acltest; ls -l /tmp/acltest
```
Create a file, grant the nobody user read/write via an ACL, then read it back — note the entry in getfacl and the trailing + in ls -l.
```
$ sudo -l 2>/dev/null; getcap -r /usr/bin 2>/dev/null | head
```
List the sudo rights you've been granted, then show which binaries carry capabilities (the modern alternative to SUID).
```
$ find /usr/bin -perm -4000 -type f 2>/dev/null | head
```
The SUID audit: list root-power binaries in /usr/bin. On a real review you'd justify each one and strip any that don't need it.

Recap

Access control = authentication (PAM) + authorization (permissions/ACLs, sudo) + auditing (logs/auditd), all guided by least privilege.
ACLs add per-user/group grants beyond owner/group/others: setfacl -m u:bob:rw, getfacl to view, the + in ls -l flags them; default ACLs make new files inherit.
sudo delegates specific root commands (who host=(run-as) commands); scope to groups + commands, edit ONLY with visudo / visudo -f.
PAM stacks auth modules per service (/etc/pam.d): pam_faillock locks after failures, pam_pwquality enforces complexity. Capabilities (setcap) replace risky SUID with a single granted power.

Task → command
Task	Command
Grant a user file access	`setfacl -m u:bob:rw file`
View / strip ACLs	`getfacl file` · `setfacl -b file`
Inherit ACLs in a dir	`setfacl -m d:u:bob:rw dir`
Edit sudo policy	`visudo` · `visudo -f /etc/sudoers.d/x`
Check my sudo rights	`sudo -l`
Lockout status / reset	`faillock --user u` · `--reset`
Audit SUID / set capability	`find / -perm -4000` · `setcap cap_net_raw+ep f`

Access Control: ACLs, sudo & PAM

The layers of access control

POSIX ACLs — beyond owner/group/others

sudo — delegate admin, least privilege

PAM — the authentication framework

Harden privilege: SUID review and capabilities

Practice in your live terminal