Originally posted by asdfblah
View Post
It therefore follows logically, that if one cares about PID1, it is vital to secure PID's that has an reachable attack surface like webservers.
When it comes to supervising and protecting processes, systemd really shines; Thanks to inbuilt easy support for kernel capabilities, it is trivial to lock down such exposed processes.
Take for example the option: "NoNewPrivileges=" If that is enabled when the process is started, it can never ever gain new privileges. So no easy privilege escalation for the intruder.
Other options sets capabilities bounds, another can even be used to white/black-list exactly what systemcalls the process (and all its children) are allowed to use. White/black-list what directories a certain process can see etc.
More examples here:
On Linux kernel capabilities:
The great thing about all this extra security that systemd can provide, is that much of it can be used without end users doing anything. The options comes for "free" in the distros unit files. There is no need for changing the programs either, so developers doesn't have to restrict themselves or to read up on security aspects they don't care about.
We are not yet in security Nirvana where every application and every running process is properly sand-boxed, but systemd security on top of a MAC like SElinux is getting much closer.
Those really serious about locking down their systems can of course start using some of the more hardcore systemd options right away. As an interesting fact, even PID1 (systemd) can be capability bound, meaning that it can be restricted to only see a limited part of the system, and only use certain features, even though it runs as root. So even compromising PID1 doesn't necessarily mean unrestricted root control.
Comment