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