Lion Cipher Lab

Sandbox a systemd service: drop its power with exec directives and score it with systemd-analyze

• Cyber / Security Engineer
• Intermediate
• ~60 min
• Free · no account required

Why it matters

Almost every daemon on a Linux box starts life with far more power than its job requires: it can write anywhere its user can, see the real /tmp and every other process's files there, open raw and packet sockets, load kernel modules, call the entire system-call surface, and keep a fistful of capabilities it will never use. That surplus power is exactly what an attacker inherits the moment they exploit the service — the gap between what a program NEEDS and what it CAN do is the blast radius of every compromise. systemd already runs your services, and it can strip that surplus on the way up with…

What you'll learn

• the idea that most services run with far more power than they need — and that systemd can drop it per-unit
• scoring a unit's attack surface with `systemd-analyze security` and reading the exposure score (0 = locked down, ~10 = wide open)
• reading the per-setting table to see which sandbox directives are set, unset, and how much each is worth
• writing a drop-in override with `systemctl edit` instead of hacking the shipped unit file
• the high-value exec directives: NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, PrivateDevices, the Protect* kernel switches
• narrowing the kernel interface a service can touch: SystemCallFilter=@system-service, RestrictAddressFamilies, RestrictNamespaces, CapabilityBoundingSet
• granting back exactly one writable path with ReadWritePaths after ProtectSystem=strict makes the filesystem read-only
• proving each restriction BITES — a write to /etc fails, an unexpected socket family fails — and watching the score drop as you add directives
• diagnosing an over-restricted unit from `journalctl -u` and loosening the one directive that broke it
• knowing why this is namespaces + seccomp + capabilities, not a labelling MAC, and how it complements SELinux/AppArmor

Steps in this lab

1. The one idea: your services run with power they never use
2. Get a real systemd box — and why WSL1 and most containers will not do
3. Stand up a small service to harden
4. Baseline: score the unhardened unit and read the table
5. Harden with a drop-in — and what each directive buys you
6. Prove it bites, and watch the score fall
7. The tuning reality: over-restrict, read the journal, loosen one thing
8. The judgment: what this is, what it is not, and the pro workflow

Open the full interactive lab →