Systemd Service Hardening?

goose4 · August 26, 2025, 1:47am

So I was learning about the options for Systemd services for restricting or in another word “hardening” services.

This made me question does Kicksecure deploy certain hardening for it’s services or certain Kicksecure specific services?

These are some interesting options I will note here:

PrivateNetwork=yes/no
Gives the service its own network namespace. It can’t see or use the host’s network interfaces unless you explicitly bind sockets. Seems useful to prevent leaks or prevent services from being ran without networking?

PrivatePIDs=yes/no
Gives a service an isolated view of the process table, which is a useful “defense in depth” measure, especially for daemons that don’t need to inspect or manage other system processes.

PrivateTmp=yes/no
Provides a private /tmp and /var/tmp for the service, isolating it from the host’s temporary directories. One service can’t read temporary files left by another service, which mitigates attacks that rely on guessing or stealing temp‑file names.

MemoryDenyWriteExecute=yes/no
Remounts parts of the filesystem read‑only (or makes the whole tree read‑only) for the service. (helps mitigate code‑injection attacks).

ProtectSystem=full/strict/yes
Remounts parts of the filesystem read‑only (or makes the whole tree read‑only) for the service.

There is many others but these few caught my eye.

arraybolt3 · August 26, 2025, 2:21am

I don’t think we harden specific “third-party” services yet, but we definitely use these kinds of things for applicable services in Kicksecure and Whonix. See sdwdate/usr/lib/systemd/system/sdwdate.service at master · Kicksecure/sdwdate · GitHub for instance, there’s a whole battery of hardening options enabled here, including a syscall filter.

Quiksilver · August 27, 2025, 6:12pm

@arraybolt3
On the USBGuard thread you mentioned CUPS, does systemd support a drop in file? it looks like documentation states it does?

Along with a unit file foo.service, a “drop-in” directory foo.service.d/ may exist. All files with the suffix “.conf” from this directory will be merged in the alphanumeric order and parsed after the main unit file itself has been parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Each drop-in file must contain appropriate section headers. For instantiated units, this logic will first look for the instance “.d/” subdirectory (e.g. “foo@bar.service.d/”) and read its “.conf” files, followed by the template “.d/” subdirectory (e.g. “foo@.service.d/”) and the “.conf” files there. Moreover, for unit names containing dashes (“-”), the set of directories generated by repeatedly truncating the unit name after all dashes is searched too. Specifically, for a unit name foo-bar-baz.service not only the regular drop-in directory foo-bar-baz.service.d/ is searched but also both foo-bar-.service.d/ and foo-.service.d/. This is useful for defining common drop-ins for a set of related units, whose names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose systematic naming structure is built around dashes as component separators. Note that equally named drop-in files further down the prefix hierarchy override those further up, i.e. foo-bar-.service.d/10-override.conf overrides foo-.service.d/10-override.conf.

systemd.unit

Couldn’t we create a CUPS drop in /etc/systemd/system/cups.service.d/hardening.conf that would apply some hardened options that would essentially mitigate:

WAN / public internet: a remote attacker sends an UDP packet to port 631. No authentication whatsoever.
LAN: a local attacker can spoof zeroconf / mDNS / DNS-SD advertisements (we will talk more about this in the next writeup ) and achieve the same code path leading to RCE.

I don’t think the package manager would ever touch it either with upgrades to CUPS?

Quiksilver · August 27, 2025, 6:13pm

Thanks for sharing this info I was not aware of this. PrivateNetwork=yes/no looks like a good option for CUPS and others we don’t need network access.

Patrick · August 27, 2025, 6:46pm

Yes, systemd configuration snippet drop-in support is amazing.

(As a distribution we should use folder /usr/lib/systemd/system rather than /etc.)

Any systemd hardening options:

Please try to submit them upstream. (Such as to cups.) If that does not work,
Submit them to Debian.
Only then consider submitting these to Kicksecure.

This is for the purpose of maintainability.

Harden all system services by default

opened 11:41AM - 17 Mar 24 UTC

closed 12:36PM - 16 Sep 25 UTC

monsieuremre

Let's make use of systemd sandboxing mechanisms to harden all services by defaul…t, whitelisting any services where necessary. * Big time advantage: not bothering to sandbox single services one by one, we sandbox everything as much as we can by default and exempt services where applicable. We can do this only for very obvious privileges that are only required by a very limited number of known services. It will still bring a lot of value in hardening. * Step 1: Create a global hardened drop in for all services Under ```/etc/systemd/system/service.d``` create ```25_security-misc.conf```, with the content: ``` [Service] ProtectProc=invisible ProcSubset=pid NoNewPrivileges=true SecureBits=noroot-locked ProtectClock=true ProtectHostname=true RestrictNamespaces=true LockPersonality=true PrivateTmp=yes ProtectHome=yes ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes RestrictSUIDSGID=true MemoryDenyWriteExecute=true RemoveIPC=true UMask=0077 # InaccessiblePaths=/sys NoExecPaths=/ ExecPaths=/usr/sbin/ /usr/lib /usr/lib64 /usr/bin PrivateDevices=true ``` * Step 2: Whitelist vital system components so that we don't actually die * For common and used time synchronization daemons, such as systemd-timesyncd, create the following drop-in: ``` [Service] ProtectClock=false ``` * For the systemd-login daemon, the following drop-in: ``` [Service] ProcSubset=all ProtectProc=false ``` * For systemd-modules-load and quite possibly other services, we need enable sticking modules to the kernel and stuff: ``` [Service] ProtectKernelModules=yes ProtectKernelTunables=yes ``` * For systemd-journald and auditd and if applicable other known logging daemons, the following drop in: ``` [Service] ProtectKernelLogs=no ``` * This is an extensive list. ```RestrictNamespaces=true``` probably needs exemption for apt and possibly some other privileged things. * ```LockPersonality=true``` might break random virtual box things, so that might be left out if necessary. * ```MemoryDenyWriteExecute=true``` might need exemption for desktop environments especially when using xorg, and probably some other things, for now not clear without testing. * ```RemoveIPC=true``` will most certainly break xorg, so DE components that rely on xorg will need drop-ins. * ```ProtectHostname``` needs an exception for services that need that for sure, what those are yet to be cleared. * PrivateDevices need exemption for services that do mounting and unmounting, only a few of them are there. Mount units need no exception, only services do. * Other things should not break anything given the exception drop-ins. Not tested this except for ProtectProc, which works as I intended. One exception drop-in does the job. So they might break more, and more exception drop-ins might be required. Will create a pull when I find the time to write a test version and actually test it.

github.com/systemd/systemd

Feature Request: Conditional Application of systemd Drop-In Files

opened 05:04PM - 17 Mar 24 UTC

adrelanos

needs-discussion 🤔 pid1

### Component systemd ### Is your feature request related to a problem? Please… describe Currently, systemd supports the use of drop-in files to extend or override configuration settings for unit files. While systemd provides the `ConditionPathExists` directive to conditionally start a service based on the existence of a file or directory, there is no built-in mechanism to conditionally apply drop-in files based on custom conditions within those files. It would be highly beneficial to have a feature in systemd that allows for the conditional application of drop-in files based on custom conditions. This would provide users with greater flexibility and control over the configuration of systemd units. A specific example would be the following one: * https://github.com/Kicksecure/security-misc/issues/213 Complex hardening would be enabled by default. But to easily opt-in/out the additional hardening, to simplify testing, a status file would be helpful. ### Describe the solution you'd like Introduce a new directive, such as `ConditionDropIn`, that allows users to specify custom conditions within drop-in files themselves. This directive could accept a condition expression similar to other systemd directives, enabling users to define conditions based on various factors such as the existence of specific files, system properties, environment variables, or other runtime conditions. Example: `/lib/systemd/system/myservice.service.d/50_drop-in.conf` ``` [Service] ConditionDropIn=Exists:/path/to/status/file # Additional configuration specific to the condition, which is disregarded if the status file does not exist. ``` In this example, the drop-in file `50_user.conf` would only be applied if the file `/path/to/status/file` exists. ### Describe alternatives you've considered Packaging, scripting. ### The systemd version you checked that didn't have the feature you are asking for _No response_

Patrick · September 16, 2025, 12:37pm

github.com/Kicksecure/security-misc

Harden all system services by default

opened 11:41AM - 17 Mar 24 UTC

closed 12:36PM - 16 Sep 25 UTC

monsieuremre

Let's make use of systemd sandboxing mechanisms to harden all services by defaul…t, whitelisting any services where necessary. * Big time advantage: not bothering to sandbox single services one by one, we sandbox everything as much as we can by default and exempt services where applicable. We can do this only for very obvious privileges that are only required by a very limited number of known services. It will still bring a lot of value in hardening. * Step 1: Create a global hardened drop in for all services Under ```/etc/systemd/system/service.d``` create ```25_security-misc.conf```, with the content: ``` [Service] ProtectProc=invisible ProcSubset=pid NoNewPrivileges=true SecureBits=noroot-locked ProtectClock=true ProtectHostname=true RestrictNamespaces=true LockPersonality=true PrivateTmp=yes ProtectHome=yes ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes RestrictSUIDSGID=true MemoryDenyWriteExecute=true RemoveIPC=true UMask=0077 # InaccessiblePaths=/sys NoExecPaths=/ ExecPaths=/usr/sbin/ /usr/lib /usr/lib64 /usr/bin PrivateDevices=true ``` * Step 2: Whitelist vital system components so that we don't actually die * For common and used time synchronization daemons, such as systemd-timesyncd, create the following drop-in: ``` [Service] ProtectClock=false ``` * For the systemd-login daemon, the following drop-in: ``` [Service] ProcSubset=all ProtectProc=false ``` * For systemd-modules-load and quite possibly other services, we need enable sticking modules to the kernel and stuff: ``` [Service] ProtectKernelModules=yes ProtectKernelTunables=yes ``` * For systemd-journald and auditd and if applicable other known logging daemons, the following drop in: ``` [Service] ProtectKernelLogs=no ``` * This is an extensive list. ```RestrictNamespaces=true``` probably needs exemption for apt and possibly some other privileged things. * ```LockPersonality=true``` might break random virtual box things, so that might be left out if necessary. * ```MemoryDenyWriteExecute=true``` might need exemption for desktop environments especially when using xorg, and probably some other things, for now not clear without testing. * ```RemoveIPC=true``` will most certainly break xorg, so DE components that rely on xorg will need drop-ins. * ```ProtectHostname``` needs an exception for services that need that for sure, what those are yet to be cleared. * PrivateDevices need exemption for services that do mounting and unmounting, only a few of them are there. Mount units need no exception, only services do. * Other things should not break anything given the exception drop-ins. Not tested this except for ProtectProc, which works as I intended. One exception drop-in does the job. So they might break more, and more exception drop-ins might be required. Will create a pull when I find the time to write a test version and actually test it.

github.com/systemd/systemd

Feature Request: Conditional Application of systemd Drop-In Files

opened 05:04PM - 17 Mar 24 UTC

adrelanos

needs-discussion 🤔 pid1

### Component systemd ### Is your feature request related to a problem? Please… describe Currently, systemd supports the use of drop-in files to extend or override configuration settings for unit files. While systemd provides the `ConditionPathExists` directive to conditionally start a service based on the existence of a file or directory, there is no built-in mechanism to conditionally apply drop-in files based on custom conditions within those files. It would be highly beneficial to have a feature in systemd that allows for the conditional application of drop-in files based on custom conditions. This would provide users with greater flexibility and control over the configuration of systemd units. A specific example would be the following one: * https://github.com/Kicksecure/security-misc/issues/213 Complex hardening would be enabled by default. But to easily opt-in/out the additional hardening, to simplify testing, a status file would be helpful. ### Describe the solution you'd like Introduce a new directive, such as `ConditionDropIn`, that allows users to specify custom conditions within drop-in files themselves. This directive could accept a condition expression similar to other systemd directives, enabling users to define conditions based on various factors such as the existence of specific files, system properties, environment variables, or other runtime conditions. Example: `/lib/systemd/system/myservice.service.d/50_drop-in.conf` ``` [Service] ConditionDropIn=Exists:/path/to/status/file # Additional configuration specific to the condition, which is disregarded if the status file does not exist. ``` In this example, the drop-in file `50_user.conf` would only be applied if the file `/path/to/status/file` exists. ### Describe alternatives you've considered Packaging, scripting. ### The systemd version you checked that didn't have the feature you are asking for _No response_