Gentoo Archives: gentoo-dev

From: John Helmert III <ajak@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units
Date: Mon, 22 Aug 2022 18:17:02
Message-Id: YwPIFctEkGJlzToW@gentoo.org
In Reply to: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units by Kenton Groombridge
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

Attachments

File name MIME type
signature.asc application/pgp-signature