Repository navigation
Harden all system services by default #213
Description
Let's make use of systemd sandboxing mechanisms to harden all services by default, 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=trueprobably needs exemption for apt and possibly some other privileged things. LockPersonality=truemight break random virtual box things, so that might be left out if necessary.MemoryDenyWriteExecute=truemight need exemption for desktop environments especially when using xorg, and probably some other things, for now not clear without testing.RemoveIPC=truewill most certainly break xorg, so DE components that rely on xorg will need drop-ins.ProtectHostnameneeds 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.
Activity
adrelanos commentedon Mar 17, 2024
Let's hope this doesn't create a lot issues infeasible to fix.
Folder needs to be
/lib/systemd/system/service.d. As per:https://www.kicksecure.com/wiki/Dev/About_Debian_Packaging#use_/usr_instead_of_/etc
Some mechanism to test this would be good:
roddhjav commentedon Mar 17, 2024
From my experience applying this everywhere generate a lot of breakage. Witch is fine provided the fact you:
A few years ago, I made a project like this (similar in spirit to
apparmor.dbut for systemd services), I gave up because, unlike apparmor, there is not way to audit issues (so that would probably be you first challenge if you want to commit time on this).Side note:
As these config settings change the way a service is executed, it has consequences on other tool in the OS. These tools much then be aware of this. Some example with apparmor & systemd:
NoNewPrivileges=yesprevents profile transition in apparmor (see https://apparmor.pujol.io/development/structure/#no-new-privileges)attach_disconnectedflag to the corresponding apparmor profile.Systemd tools are usually already well configured on this matter, if a setting is not enabled, there is a reason why.
If it is the correct way to implement it (allow-list instead of deny-list), it is quite complex and time consuming: you need to test every possible service and check if they need less settings. In other words, you still need to sandbox single services...
roddhjav commentedon Mar 17, 2024
Interesting, I wish I had this tool a few years ago. apparmor.d is more complex because:
It end up being much more than a list of restriction more a security construction of you OS.
adrelanos commentedon Mar 18, 2024
Would apparmor.d accomplish the same (and more) than this ticket?
adrelanos commentedon Jul 7, 2024
Please send systemd unit files improvements (systemd hardening) patches upstream to individual Debian packages so this doesn't need to be (all) carried downstream by Kicksecure. As per:
https://www.kicksecure.com/wiki/Dev/Relationship_With_Upstream#Upstream_software
adrelanos commentedon Sep 16, 2025
Out of scope for this repository.
Kicksecure ticket and stance:
https://forums.kicksecure.com/t/systemd-service-hardening/1258/5