What do you think?
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?
[1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html
[2] https://docs.arbitrary.ch/security/systemd.html
What do you think?
On Mon, Aug 22, 2022 at 2:10 PM Kenton Groombridge <[email protected]> wrote:
What do you think?
I am concerned that people will start mass filing bugs with
suggestions without fully understanding them or without testing them thoroughly. Please don't do that.
Also, ideally we would not need to provide systemd units at a distro
level, and they would instead be provided by upstream. I certainly
don't want to start installing distro-customized units where upstream
already provides unit files.
I think the best way to address this is to have packages ship unit override files instead of unit files themselves which enable these options. For example,
instead of Gentoo shipping a modified miniflux.service unit file, we can instead
install a file to /etc/system/miniflux.service.d/00gentoo.conf using the existing systemd_install_serviced helper in systemd.eclass which enables these
options.
On 25/08/2022 15.25, Kenton Groombridge wrote:
I think the best way to address this is to have packages ship unit override files instead of unit files themselves which enable these options. For example,
instead of Gentoo shipping a modified miniflux.service unit file, we can instead
install a file to /etc/system/miniflux.service.d/00gentoo.conf using the existing systemd_install_serviced helper in systemd.eclass which enables these
options.
Wouldn't the proper place for overrides installed by a distributions
package manager be
/usr/lib/systemd/system/miniflux.service.d/gentoo.conf
Wouldn't the proper place for overrides installed by a distributions package manager be
/usr/lib/systemd/system/miniflux.service.d/gentoo.conf
On 22/08/25 04:06PM, Florian Schmaus wrote:
Wouldn't the proper place for overrides installed by a distributions package
manager be
/usr/lib/systemd/system/miniflux.service.d/gentoo.conf
Yes... I was wondering that too. Currently systemd_install_serviced installs to
/etc/systemd/system instead of /usr/lib/systemd/system appears to be wrong. systemd's own documentation says distributions should be installing contents to
/usr/lib/systemd/system while /etc/systemd/system is intended for "System units
created by the administrator" (users).
We could introduce a new function to install distro-specific overrides
in [/usr]/lib/systemd/system.
On 22/08/25 01:04PM, Mike Gilbert wrote:
We could introduce a new function to install distro-specific overrides
in [/usr]/lib/systemd/system.
I think that's a good idea. systemd_{new,do}serviceconf maybe?
As I understand it these should go to /usr/lib/[...].
On Thu, 2022-08-25 at 16:06 +0200, Florian Schmaus wrote:
On 25/08/2022 15.25, Kenton Groombridge wrote:
I think the best way to address this is to have packages ship unit override >>> files instead of unit files themselves which enable these options. For example,
instead of Gentoo shipping a modified miniflux.service unit file, we can instead
install a file to /etc/system/miniflux.service.d/00gentoo.conf using the >>> existing systemd_install_serviced helper in systemd.eclass which enables these
options.
Wouldn't the proper place for overrides installed by a distributions
package manager be
/usr/lib/systemd/system/miniflux.service.d/gentoo.conf
These files are meant to be modifiable by the sysadmin, so they don't
belong in /usr.
While then can not be modified, settings made in /usr/lib/systemd/system
can be overridden by the sysadmin by placing a file in /etc/systemd/system.
I am not aware of a reason why a package manger should install systemd configuration files under /etc.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 147:11:36 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,529 |