Lesson 1.37: Sandboxing a service with systemd
If an attacker takes over a service, they get whatever that service is allowed to do. systemd can shrink that a lot with a few settings: run as a dedicated user, forbid gaining new privileges, make the operating system read-only except for the service's own data, hide home directories and devices, drop every capability. systemd-analyze security scores how exposed each service is. In the lab you compare Northwind's two services, find that the report generator runs as root with no protection, harden it with a drop-in, and confirm the result.
17 min
You will learn to
- Explain service sandboxing and least privilege
- Read systemd-analyze security output
- Write a hardening drop-in
- Run a service as a dedicated user
- Verify the new exposure score
Key terms
- NoNewPrivileges=
- The service and its children can never gain privileges, e.g. through setuid programs.
- ProtectSystem=strict
- Mounts the whole file system read-only for the service; ReadWritePaths= lists exceptions.
- Capabilities
- Root's powers split into pieces (CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN…).
- PrivateTmp=
- Gives the service its own /tmp, invisible to others.
- Exposure score
- systemd-analyze security's estimate from 0 (safe) to 10 (dangerous).
← Linux distributions · All lessons · Deleted files that still fill the disk →