In this section
LX0.9 The Linux Security Architecture
The Linux Security Architecture: What Investigators Encounter
Why Security Architecture Matters for Investigation
The security architecture of a Linux system determines two things that directly affect your investigation: what the attacker had to bypass to achieve their objective, and what evidence was generated when they did. An attacker who exploits a privilege escalation vulnerability on a system running SELinux in enforcing mode generates different evidence than the same attacker on a system with SELinux disabled. The SELinux-enforcing system has AVC (Access Vector Cache) denial logs showing every operation the attacker attempted that was blocked — a detailed record of the attacker's trial-and-error process. The SELinux-disabled system has none of this.
Understanding the security architecture also tells you what the attacker could and could not do without additional exploitation. If AppArmor confined the web server process, the attacker who compromised the web application could only access files and network connections permitted by the AppArmor profile — unless they escaped the confinement. Evidence of AppArmor escape attempts appears in the kernel log and the AppArmor audit log.
Discretionary Access Control: Traditional Unix Permissions
Try it yourself
Check the security posture of a Linux system you manage.
Check the security posture of a Linux system you manage. Run getenforce (SELinux status) or aa-status (AppArmor status). Run auditctl -l (current audit rules — how many rules are loaded? Are they the default minimal set or a comprehensive deployment?). Run find / -perm -4000 -type f 2>/dev/null | wc -l (count of SUID binaries). Run docker inspect --format '{{.HostConfig.Privileged}} {{.HostConfig.CapAdd}}' on a running container (is it privileged? What extra capabilities does it have?). Each answer tells you what evidence would be available — or absent — during an investigation of that system.
Beyond This Investigation
Security architecture knowledge is applied directly in the investigation scenarios. LX6 (Privilege Escalation) examines SUID exploitation and capability abuse. LX7 (Persistence) examines how attackers create persistence mechanisms that survive MAC enforcement. LX9 (Container Compromise) examines namespace escapes and capability-based container breakouts. LX15 (Detection Engineering) deploys auditd rules based on the investigation findings — converting the reactive evidence discovery into proactive monitoring.
# Security posture assessment — determines your evidence landscape
# MAC framework status
getenforce 2>/dev/null && echo "SELinux active" || true
aa-status 2>/dev/null && echo "AppArmor active" || true
# Audit daemon status and rule count
systemctl is-active auditd 2>/dev/null
auditctl -l 2>/dev/null | wc -l
# 3 rules = minimal (auth only). 20+ rules = comprehensive. 0 = not running.
# SUID binary count (compare against known-good baseline)
find / -perm -4000 -type f 2>/dev/null | wc -l
# Typical Ubuntu server: 15-25 SUID binaries. Significantly more = suspicious.
# SELinux denial check (if SELinux is active)
ausearch -m avc -ts recent 2>/dev/null | head -20
# AVC denials during the compromise window = attacker hitting SELinux boundariesWorked artifact — Security posture assessment:
>
Run this assessment at the start of every investigation to understand the evidence landscape.
>
System: [hostname] Distribution: [ID from os-release]
>
MAC framework: ☐ SELinux enforcing ☐ SELinux permissive ☐ SELinux disabled ☐ AppArmor enforcing ☐ AppArmor complain ☐ None
Audit daemon: ☐ auditd running (rules: ___) ☐ auditd installed but minimal rules ☐ auditd not installed
SUID binaries: Count: ___ (compare against baseline)
Capabilities: Notable: ___
Firewall: ☐ iptables ☐ nftables ☐ firewalld ☐ ufw ☐ None
>
Evidence implications: More active security layers = more evidence generated by attacker actions. Disabled/absent layers = dark zones where attacker activity is not recorded.
Myth: "SELinux should be disabled because it causes too many problems."
Reality: Disabling SELinux removes one of the most powerful forensic evidence sources on Linux. When SELinux is enforcing, every operation the attacker attempts that violates policy generates an AVC denial in the audit log — a detailed record of what they tried to access, from which process context, and whether it was blocked. Disabling SELinux eliminates this evidence source entirely. From an investigation perspective, a system with SELinux enforcing provides significantly richer evidence than one with SELinux disabled. The operational overhead of managing SELinux is the cost of having that evidence available when you need it.
Decision points: interpreting security architecture for investigation
SELinux enforcing + auditd comprehensive rules: richest evidence environment. Check AVC denials for attacker activity, check audit.log for every command executed.
AppArmor + auditd minimal: AppArmor violations in kernel log, but limited command execution evidence. Rely on bash history and /proc.
No MAC + no auditd: minimal evidence environment. Rely entirely on filesystem timestamps, bash history, log files, and /proc. This is the most common situation on production servers.
Troubleshooting: security architecture evidence gaps
SELinux was changed from enforcing to permissive during the compromise. Check ausearch -m MAC_STATUS for the timestamp. Everything after that timestamp was not constrained by SELinux — the attacker deliberately disabled it.
auditd is running but has no execve rules. Only authentication events are recorded. Command execution evidence is limited to bash history and /proc. Recommend deploying comprehensive rules for future incidents.
Cannot determine if SUID binaries are legitimate. Compare against the package manifest: dpkg -S /path/to/binary (Debian) or rpm -qf /path/to/binary (RHEL). If the binary is not owned by any package, it was placed there manually.
Check your understanding:
1. A compromised web server runs on a system with SELinux in enforcing mode. The attacker attempts to read /etc/shadow from the web server process. What happens, and what evidence is generated? 2. You find the audit log entry type=MAC_STATUS msg=audit(1711601900.123:1285): enforcing=0 old_enforcing=1. What does this tell you about the attacker's activity? 3. A Docker container has CAP_SYS_ADMIN in its capability set. Why is this forensically significant? 4. You run auditctl -l and see only 3 rules (all related to authentication). What investigation evidence will be missing, and what recommendation would you make for future incidents?
You are investigating a Linux server and discover evidence of both a cryptominer (resource abuse) and an SSH key theft (lateral movement preparation). The cryptominer is consuming 95% CPU and impacting production. Which do you address first?
Address the lateral movement first. The cryptominer is visible, noisy, and contained to this server — it is causing performance impact but not spreading. The SSH key theft is silent, potentially already exploited, and may have given the attacker access to additional servers. Contain the lateral movement risk: rotate the stolen SSH keys, check the target servers for unauthorized access, and apply network restrictions. Then address the cryptominer: kill the process, remove the binary and persistence mechanisms. Prioritizing the noisy but contained threat over the silent but spreading threat is the most common Linux IR prioritization mistake.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.