systemd: Confine services

[KellerFuchs]

This configuration change enforces by default some restriction on services:

• PrivateTmp: they get their own /tmp and /var/tmp;
• PrivateDevices: they only get to view API pseudo-devices (/dev/null, full, random, ...);
• ProtectSystem: /usr, /boot and /etc are read-only;
• ProtectHome: prevents access to /home, /root and /run/user;
• NoNewPrivileges: prevents uid changes and some other things;
• CapabilityBoundingSet: prevents use of CAP_SYS_ADMIN, CAP_DAC_OVERRIDE and CAP_SYS_PTRACE.

Some services needs specific overrides, that need to be put in systemd/system/$UNIT.d/override.conf.
The provided override are probably both suboptimal and insufficient.

WARNING: Do not merge yet. In particular, this would break sshd without #28.
This is meant, in a first time, for review only.

[daurnimator]

no newline at end of file

[daurnimator]

Normally these kind of changes are done upstream (i.e. in debian). Surely there's a some reason it's not already shipping like this?

[KellerFuchs]

Debian seems to be moving towards shipping AppArmor profiles with their packages to enforce security policy (which is incompatible with SELinux).

Having some experience with such work, I suspect it is not already done for all services (whether by using AppArmor/SELinux or in a more limited fashion through systemd's features) because it is extremely difficult to write a security policy that is strict enough to be useful, yet does not break functionality, without knowing the context in which it is used.
Also, Debian developers cannot break backwards-compatibility for already deployed & configured services.

In our case, though, we know which services are run and how they are configured.
We can, however, start off with less strict settings; PrivateTmp, PrivateDevices, ProtectSystem and ProtectHome are very unlikely to break services (with the currently-specified overrides, plus ProtectHome=false for OpenSSH or #28).

[KellerFuchs]

We should revisit this, preferably once integration testing is underway.

As a FYI, the Debian project is drafting unit files best practices that are moving in that direction: https://etherpad.fr/p/systemd-best-practices