| 1 |
Hi everyone, |
| 2 |
|
| 3 |
I noticed that there are many systemd units which are shipped by various |
| 4 |
packages which could be hardened, some further than they are currently and some |
| 5 |
that could use some hardening in general. |
| 6 |
|
| 7 |
For those who are unaware, systemd units support many options which can be used |
| 8 |
to restrict privileges of the processes run by the service. Some of these |
| 9 |
options include things like making specified paths inaccessible or read-only, |
| 10 |
setting the no_new_privs flag, protecting kernel sysctls, preventing the loading |
| 11 |
of kernel modules, applying a seccomp filter to restrict syscalls, and more. I |
| 12 |
frequently reference systemd.exec(5)[1] and this page[2] for reference. |
| 13 |
|
| 14 |
Many of these options are fairly easy to apply from a user perspective - a user |
| 15 |
only needs to harden something like miniflux.service by overriding/settings via |
| 16 |
'systemctl edit miniflux.service' (or manually editing |
| 17 |
/etc/systemd/system/miniflux.service.d/override.conf). But, I want to propose an |
| 18 |
initiative to set some of these options by default for systemd units shipped in |
| 19 |
::gentoo. |
| 20 |
|
| 21 |
Care must be taken though, as some of these options may end up breaking some |
| 22 |
functionality that could be expected by users. An example of this may be if the |
| 23 |
package maintainer made the root filesystem read-only for a service except for |
| 24 |
its private /var/lib, but a user was using an entirely different directory for |
| 25 |
the service's read-writable data. Something like this may need to be |
| 26 |
communicated via post-installation messages or simply left out by default, |
| 27 |
depending on the circumstances. On the other hand, there are many options like |
| 28 |
restricting syscalls via SystemCallFilter=@system-service or restricting |
| 29 |
privilege escalation via NoNewPrivileges=true that I think are generally safe to |
| 30 |
apply, but each service is different and needs to be handled and tested |
| 31 |
accordingly. |
| 32 |
|
| 33 |
As for getting units updated, I think a good place to start would be to create a |
| 34 |
new tracker bug for identifying packages providing systemd units that could be |
| 35 |
improved in this regard, and each bug filed could include recommendations for |
| 36 |
some of the more common options like ProtectSystem=, ProtectHome=, |
| 37 |
ProtectDevices=, and others. |
| 38 |
|
| 39 |
What do you think? |
| 40 |
|
| 41 |
[1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html |
| 42 |
[2] https://docs.arbitrary.ch/security/systemd.html |
Archives