Linux Security Controls

Linux security is layered. Traditional UID/GID permissions are only the start; modern systems also use capabilities, PAM, sudoers, LSMs such as AppArmor or SELinux, seccomp filters, audit rules, file capabilities, mount options, and container boundaries.

The practical skill is identifying which layer denied the operation.

Command Examples

id
sudo -l
getcap -r /usr/bin /usr/sbin 2>/dev/null
aa-status 2>/dev/null || true
sestatus 2>/dev/null || true
journalctl -k -g 'apparmor|SELinux|seccomp|audit'

Example output and meaning:

Permission failures can look identical at the application layer while coming from different controls.

Capabilities

Capabilities split root privileges into smaller units. A process may have permission to bind low ports, change network settings, or load modules without having every root privilege.

Useful commands:

capsh --print
grep Cap /proc/<pid>/status
getcap /path/to/binary
setcap cap_net_bind_service=+ep /usr/local/bin/server

Common capabilities:

CAP_SYS_ADMIN is intentionally broad and often equivalent to too much trust.

seccomp

seccomp filters restrict which syscalls a process may make. Containers often use seccomp profiles to reduce kernel attack surface.

Symptoms:

• syscall returns EPERM,
• process receives SIGSYS,
• container works with an unconfined profile but fails with the default profile,
• audit logs mention seccomp.

Checks:

grep Seccomp /proc/<pid>/status
journalctl -k -g seccomp

AppArmor and SELinux

Linux Security Modules add policy beyond Unix permissions.

If mode bits look correct but access is denied, check LSM policy and labels/profiles.

PAM, sudoers, and auditd

PAM controls login and authentication flows. sudoers controls delegated privilege. auditd records policy-relevant events.

sudo visudo -c
sudo -l -U <user>
grep -R '^[^#]' /etc/pam.d
auditctl -s 2>/dev/null || true
ausearch -m AVC,USER_AUTH,USER_ACCT,SYSCALL 2>/dev/null | tail

PAM failures often appear as SSH or sudo failures, but the root cause may be account expiration, group membership, MFA policy, or module order.

setuid, setgid, and File Capabilities

setuid and setgid binaries execute with owner or group privileges. File capabilities are narrower alternatives for specific privileges.

find / -perm -4000 -type f -xdev 2>/dev/null
find / -perm -2000 -type f -xdev 2>/dev/null
getcap -r / 2>/dev/null

Audit these regularly. Unexpected setuid binaries and broad file capabilities are high-value escalation paths.

Containers and Boundaries

Container security combines namespaces, cgroups, capabilities, seccomp, LSMs, read-only filesystems, user namespaces, and runtime policy.

Important questions:

• Is the container privileged?
• Which capabilities were added or dropped?
• Is host networking, host PID, or hostPath mounted?
• Is seccomp unconfined?
• Are AppArmor or SELinux labels applied?
• Is the root filesystem read-only?

Runbook

1. Capture the exact operation and error: path, syscall, user, process, namespace.
2. Check Unix permissions, ACLs, owner, group, and mount options.
3. Check capabilities and file capabilities.
4. Check seccomp mode and denial logs.
5. Check AppArmor or SELinux profile/label denials.
6. Check PAM/sudoers/audit logs for auth and privilege failures.
7. Fix the narrowest policy layer instead of granting broad root or privileged container access.

Study Cards

References

• capabilities(7)
• seccomp(2)
• AppArmor documentation
• SELinux project documentation
• sudoers(5)