On Mon, Aug 22, 2022 at 02:10:47PM -0400, Kenton Groombridge wrote:
> Hi everyone,
> 
> I noticed that there are many systemd units which are shipped by various
> packages which could be hardened, some further than they are currently and 
> some
> that could use some hardening in general.
> 
> For those who are unaware, systemd units support many options which can be 
> used
> to restrict privileges of the processes run by the service. Some of these
> options include things like making specified paths inaccessible or read-only,
> setting the no_new_privs flag, protecting kernel sysctls, preventing the 
> loading
> of kernel modules, applying a seccomp filter to restrict syscalls, and more. I
> frequently reference systemd.exec(5)[1] and this page[2] for reference.
> 
> Many of these options are fairly easy to apply from a user perspective - a 
> user
> only needs to harden something like miniflux.service by overriding/settings 
> via
> 'systemctl edit miniflux.service' (or manually editing
> /etc/systemd/system/miniflux.service.d/override.conf). But, I want to propose 
> an
> initiative to set some of these options by default for systemd units shipped 
> in
> ::gentoo.
> 
> Care must be taken though, as some of these options may end up breaking some
> functionality that could be expected by users. An example of this may be if 
> the
> package maintainer made the root filesystem read-only for a service except for
> its private /var/lib, but a user was using an entirely different directory for
> the service's read-writable data. Something like this may need to be
> communicated via post-installation messages or simply left out by default,
> depending on the circumstances. On the other hand, there are many options like
> restricting syscalls via SystemCallFilter=@system-service or restricting
> privilege escalation via NoNewPrivileges=true that I think are generally safe 
> to
> apply, but each service is different and needs to be handled and tested
> accordingly.
> 
> As for getting units updated, I think a good place to start would be to 
> create a
> new tracker bug for identifying packages providing systemd units that could be
> improved in this regard, and each bug filed could include recommendations for
> some of the more common options like ProtectSystem=, ProtectHome=,
> ProtectDevices=, and others.
> 
> What do you think?

This would be a great improvement! systemd users can also see some of
this via `systemd-analyze security`.

> [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html
> [2] https://docs.arbitrary.ch/security/systemd.html

Attachment: signature.asc
Description: PGP signature

Reply via email to