Systemd has hardening features that are useful, but - unless I'm missing an obvious resource/documentation - really frustrating to use/debug/figure out.

There's a long list of flags and settings you can give a service unit. For example, to only allowing binding on TCP port 4883, you use SocketBindAllow=tcp:4883. Or, to create a new filesystem at /tmpand/var/tmp, something you'll almost always want to do, you use PrivateTmp=yes. You can use RootDirectoryto setup a chroot and then useBindPathsandReadOnlyBindPaths` to add bind mounts specific to the unit.

You can use systemd-analyze security UNIT to get a security breakdown and a score. Aolium has a score of 1.0 (lower is better). You can also run systemd-analyze security without any unit and you'll get a security summary of all units. This is where things are depressing: in a standard ubuntu install, the overwhelming majority score around 9.5 which is considered "unsafe" (I assume this isn't a ubuntu-specific issue though). As a random but certainly not isolated example, running systemd-analyze on NGINX's sample systemd configuration (https://www.nginx.com/resources/wiki/start/topics/examples/systemd/) yields "9.2 UNSAFE 😨"

I can only assume that part of the issue is that it's pretty hard to figure out what/how to configure things and when things don't work, it's hard to figure out why. For example, aolium runs with SystemCallFilter=~@clock @cpu-emulation @privileged @module @raw-io @reboot @debug @mount and it works, but is it right, should there be more? In the past, I've largely gotten things working by adding one setting at a time and seeing if/how it works.

You can use systemd-run $FLAGS -- shell to start a shell with the given flags to get access to the environment that the service will run in. Here's an example of using systemd-run with ProtectHome=yes to show how it makes /home (and /root) inaccessible:

root@:/tmp# systemd-run -p ProtectHome=yes --shell
Running as unit: run-u176.service
Press ^] three times within 1s to disconnect TTY.
root@:/tmp# ls -lah /home/
total 4.0K
d---------  2 root root   40 Jul 18 04:00 .
drwxr-xr-x 19 root root 4.0K Jul 18 04:02 ..

It's useful, but really just the bare minimum.

It'd be great to get better documentation (something aimed more at us accidental devops). It would be great if vendors could do a better job with their own units, both to make us all more secure and to act as templates. I'm not sure what can be done directly with respect to tooling, but as a start, getting more detailed error messages on failure, would help.