Listen to this Post
Introduction:
Linux security is built on layered mechanisms—from file permissions and special bits to kernel-level defenses like ASLR and seccomp. Understanding these pillars is essential for sysadmins, pentesters, and DevSecOps engineers to both protect and assess modern Linux systems. This article distills core concepts from “The Linux Security Journey” into actionable commands, configurations, and step‑by‑step tutorials.
Learning Objectives:
- Identify and exploit/audit SUID/SGID binaries and capability leaks.
- Configure ASLR, seccomp profiles, and mandatory access controls (AppArmor/SELinux).
- Implement firewall rules with nftables and harden authentication via PAM and ACLs.
You Should Know:
- SUID, SGID, and Sticky Bit – Privilege Escalation Vectors
Linux’s special permission bits allow executables to run with the owner’s or group’s privileges. While `passwd` needs SUID to modify/etc/shadow, misconfigured SUID binaries are a top privilege escalation path.
Step‑by‑step guide to audit and secure special bits:
Find all SUID/SGID binaries:
Linux: find SUID files find / -perm -4000 -type f 2>/dev/null Find SGID files find / -perm -2000 -type f 2>/dev/null Find sticky bit directories (e.g., /tmp) find / -perm -1000 -type d 2>/dev/null
Check a binary’s permissions:
ls -l /usr/bin/passwd Output: -rwsr-xr-x → 's' in owner field = SUID
Remove unwanted SUID (hardening):
sudo chmod u-s /path/to/binary
Windows equivalent (rare, but Setuid-like via service permissions):
Find services with weak permissions (PowerShell) Get-WmiObject win32_service | Select-Object Name, StartName Use sc.exe to check DACL sc sdshow <ServiceName>
Exploitation note: A world‑writable SUID binary or a binary that calls `system()` with relative paths can lead to root. Always audit with:
strings /bin/su | grep "/bin/"
2. Linux Capabilities – Beyond Root’s All‑or‑Nothing
Capabilities split root’s monolithic power into 40+ distinct privileges (e.g., CAP_NET_ADMIN, CAP_SYS_ADMIN). A process can run as non‑root but still bind a low port using CAP_NET_BIND_SERVICE.
Step‑by‑step to list, add, and remove capabilities:
View capabilities of a running process:
Install libcap2-bin first sudo apt install libcap2-bin -y Check process by PID getpcaps 1234
List capabilities of a binary file:
getcap /usr/bin/ping Output: /usr/bin/ping = cap_net_raw+ep
Add capability to a script/binary (e.g., allow python to open raw sockets):
sudo setcap cap_net_raw+ep /usr/bin/python3 Verify getcap /usr/bin/python3
Remove all capabilities:
sudo setcap -r /usr/bin/python3
Check for dangerous capability sets (privilege escalation):
Find binaries with any capabilities getcap -r / 2>/dev/null Look for CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SETUID
Windows counterpart: Privileges like `SeDebugPrivilege` or `SeTakeOwnershipPrivilege` in access tokens. Enumerate with:
whoami /priv
3. ASLR & seccomp – Kernel‑Level Hardening
ASLR randomizes memory addresses (stack, heap, libraries) making buffer overflow exploitation unreliable. seccomp restricts which syscalls a process can invoke—used by Docker, Chrome, and systemd services.
Step‑by‑step to check and tune ASLR:
View current ASLR setting (0=off, 1=partial, 2=full):
cat /proc/sys/kernel/randomize_va_space Typical value: 2
Temporarily disable ASLR (for debugging or exploit dev):
sudo sysctl -w kernel.randomize_va_space=0
Permanent setting: Edit `/etc/sysctl.conf` and add `kernel.randomize_va_space=2`.
Step‑by‑step to apply seccomp profiles with `strace` and seccomp-tools:
Install seccomp tools:
sudo apt install seccomp strace -y gem install seccomp-tools for analysis
Trace syscalls of a program:
strace -c -f ./your_binary -c summarizes syscall counts
Generate a seccomp profile for Docker (example block execve):
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{"names": ["execve"], "action": "SCMP_ACT_ERRNO"}
]
}
Apply with: `docker run –security-opt seccomp=profile.json …`
Test seccomp from C (using libseccomp):
include <seccomp.h> scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL); seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 0); seccomp_load(ctx);
- LSM – AppArmor vs SELinux (Mandatory Access Control)
Linux Security Modules provide MAC. AppArmor (path‑based, easier) and SELinux (label‑based, granular) confine applications even when running as root.
Step‑by‑step to enforce AppArmor profiles:
Check status:
sudo aa-status
Put a profile into complain mode (logs but doesn’t block):
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
Enforce a profile:
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
Create a simple custom profile for a script:
sudo aa-genprof /path/to/your/script Follow interactive prompts
For SELinux (RHEL/CentOS):
Check mode: `getenforce`
Set permissive: `sudo setenforce 0`
View denials: `sudo ausearch -m avc -ts recent`
Windows analogy: Mandatory Integrity Control (MIC) and AppLocker.
5. nftables – Modern Firewall Replacement for iptables
nftables is the successor to iptables, offering better performance and a unified syntax.
Step‑by‑step basic nftables ruleset:
Install and enable:
sudo apt install nftables -y sudo systemctl enable nftables
List current rules:
sudo nft list ruleset
Add a basic IPv4 table and chain:
sudo nft add table ip filter
sudo nft add chain ip filter input { type filter hook input priority 0\; policy drop\; }
Allow SSH and established connections:
sudo nft add rule ip filter input tcp dport 22 accept sudo nft add rule ip filter input ct state related,established accept
Save rules persistently:
sudo nft list ruleset > /etc/nftables.conf
Migrate from iptables: `sudo iptables-restore-translate -f iptables.rules`
Windows firewall via PowerShell:
New-NetFirewallRule -DisplayName "Allow SSH" -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow
- PAM and ACLs – Fine‑Grained Authentication & Permissions
PAM (Pluggable Authentication Modules) stacks rules for login, sudo, sshd. ACLs extend POSIX permissions beyond user/group/other.
Step‑by‑step PAM hardening (limit sudo attempts):
Edit `/etc/pam.d/sudo`:
sudo nano /etc/pam.d/sudo Add line: auth required pam_faillock.so preauth audit deny=3 unlock_time=300
Enforce password complexity: Install `libpam-pwquality` and edit `/etc/pam.d/common-password`.
Step‑by‑step ACL usage:
Install ACL tools:
sudo apt install acl -y
Grant read access to specific user on a file:
setfacl -m u:alice:r secret.txt
View ACL:
getfacl secret.txt
Remove ACL entry:
setfacl -x u:alice secret.txt
Make ACLs recursive: `setfacl -R -m g:devs:rwx /project`
Windows equivalent: `icacls` command – `icacls C:\secret /grant Alice:R`
7. chroot – Lightweight Jails (Not Real Security)
chroot changes the root directory for a process, but root users can break out via `chroot` escapes or mounting /proc.
Step‑by‑step create a minimal chroot jail:
Create jail directory:
sudo mkdir -p /jail/bin /jail/lib64 /jail/lib/x86_64-linux-gnu
Copy bash and dependencies:
sudo cp /bin/bash /jail/bin/
ldd /bin/bash | awk '{print $3}' | xargs -I {} sudo cp {} /jail/lib64/ 2>/dev/null
chroot into it:
sudo chroot /jail /bin/bash
Escape demonstration (if /proc is mounted):
Inside jail, run `mkdir /proc` then `mount -t proc none /proc` (requires root in jail). Then cat /proc/self/cwd/../../../etc/shadow.
Hardening: Use `pivot_root` or better: namespaces + seccomp (Docker style). For Windows, consider `AppContainer` or Job Objects.
What Undercode Say:
- Key Takeaway 1: SUID and capabilities are double‑edged swords – always audit `find / -perm -4000` and `getcap -r /` on production systems.
- Key Takeaway 2: ASLR + seccomp + LSM form the modern Linux defense‑in‑depth triad; misconfiguring any one reduces exploit difficulty from “hard” to “trivial.”
Analysis: The post by Héctor Joaquín correctly emphasizes that Linux security is not a single tool but a stack of kernel features often ignored by administrators. Many breaches occur because teams disable ASLR for “performance” or run containers with --privileged. The shift to eBPF and cgroupv2 is making seccomp and capabilities even more critical. Meanwhile, Windows environments are adopting similar concepts (CFG, ACG, WDAC). The biggest gap remains knowledge: most Linux admins cannot differentiate between `RUID` and EUID, yet those differences enable `sudo` vulnerabilities. The provided commands—from `getpcaps` to `nft` rules—should be part of every monthly hardening checklist.
Prediction:
As cloud workloads and containerized microservices dominate, traditional Linux security models will evolve toward zero‑trust kernel primitives. We predict that by 2028, eBPF‑based security policies will replace most iptables and seccomp usage, and capability‑dropping will become mandatory in Kubernetes admission controllers. Misconfigured SUID binaries will be automatically flagged by CI/CD pipelines using static analyzers (e.g., checksec). Additionally, AI‑driven anomaly detection on syscall sequences (via seccomp‑notify) will catch novel exploits before they escalate. The “Linux Security Journey” is just beginning—automation and real‑time kernel monitoring are the next frontiers.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: H%C3%A9ctor Joaqu%C3%ADn – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
