SysD seems to be unstoppable in the Linux world. I personally have made peace with it.
I even appreciate the logging functions with journalctl, for example, and think they are much more pleasant than the confusing and insecure Syslog.
It would go beyond the scope of this article to explain everything, so here is just a brief outline:
Systemd is configured with unit files.
Most programs store their service files in /etc/system/system/
There are service files, timer configurations, device and routine configurations.
Each unit creates a journal, which can be read out with journalctl.
If you look at any unit file i /etc/systemd/system/ you will always see the same structure of [Unit], [Service] and [Install].
Example configuration at NGINX:
SystemD has an in-house exposure level function called systemd-analyze security which can be used to check the security settings:
systemd-analyze security nginx.service
NGINX gets the value 9.6 and is considered unsafe.
But what this output also does is display all the flags that make it unsafe.
Almost every flag is a boolean value. Here you have to try around until you get everything on green.
Not every service needs to be run with root privileges. With NGINX, this is only required for port binding.
This right can be borrowed from root:
With this setting NGINX can now be started as www-data.
My service file now looks like this after testing forever with systemctl edit --full nginx.service and journalctl -fu nginx.service:
My exposure level has dropped from just under 10 to 5.
The smiley looks less sad now.
You can do that with any unit file!
Like any sandbox, you can break out of it with enough zeal. SystemD sandboxing, for example, only checks the interprocess communication (IPC) to a simple degree, through which a process can break out of the barrier via BUS, for example. Either way, however, the sandboxing argument is a huge step towards security improvement and makes it harder for attackers to take over your system.