[SOLVED] Is it possible to further Sandbox/Harden systemd services?

noob4lnx · 2022-09-23 22:26:44

This thread is generic and different from my other systemd question. I want to know if its feasible and recommendable to further sandbox the default systemd service files ? See below

 systemd-analyze security

UNIT                                 EXPOSURE PREDICATE HAPPY
archlinux-keyring-wkd-sync.service        2.0 OK        ?
auditd.service                            8.7 EXPOSED   ?
dbus.service                              9.6 UNSAFE    ?
dm-event.service                          9.5 UNSAFE    ?
emergency.service                         9.5 UNSAFE    ?
getty@tty1.service                        9.6 UNSAFE    ?
rc-local.service                          2.5 OK        ?
rescue.service                            9.5 UNSAFE    ?
shadow.service                            9.6 UNSAFE    ?
systemd-ask-password-console.service      9.4 UNSAFE    ?
systemd-ask-password-wall.service         9.4 UNSAFE    ?
systemd-journald.service                  4.3 OK        ?
systemd-logind.service                    2.8 OK        ?
systemd-networkd.service                  2.6 OK        ?
systemd-resolved.service                  2.1 OK        ?
systemd-rfkill.service                    9.4 UNSAFE    ?
systemd-timesyncd.service                 2.1 OK        ?
systemd-udevd.service                     6.8 MEDIUM    ?

I understand the "UNSAFE" ratings are just relative to the level of how a particular service is sandboxed and provides no real objective indication to system security but I wonder if anyone actually makes efforts to tighten some systemd services / or if the default settings are already optimized to max security/usability ( which I think is the case but I just like some confirmation here as a newb to systemd ) . Thank you

Extra question: other than sandboxing individual services (above) are there other ways Linux users take to harden systemd? I can only think of recompiling systemd manually with certain compiler flags (any recomendations?) also to alter the binary symbol table... ?

Thanks again and have a nice day

Last edited by noob4lnx (2023-03-14 14:19:58)

mpan · 2022-09-23 23:01:28

Yes, it is absolutely possible. For example my tor.service is tweaked to get the score of 3.2, compared to landing in upper ranges by default.

The real question is however not if it’s possible, but if it’s needed. From the invocation to the way results are presented, `systemd-analyze security` is misleading in what it represents. It does not measure level of security or actual risk. What it does is estimating exposure, based on attack surfaces present. You can’t arbitrarily reduce exposure, because it is often inherent to the function of the service. The goal of reading `systemd-analyze security` should be primarily knowing the exposure, not aiming for nice numbers.

To make an analogy: by invoking `systemd-analyze security your-house` you would get poor score, because your house contains attack surfaces like windows and doors, and misses an underground bunker with 5 years supply of canned food. Obviously you do want to have doors and windows in your house, despite the risk, and probably can live without a bunker. Equally many services get poor score, because they must have some attack surfaces open to do their job.

For many services it is possible to improve the situation, but that becomes tedious work, requiring understanding of what the process does, usually with little gains, but putting you at the risk of preventing the service from working. In particular upon an update. At some point improving `systemd-analyze security` rating may become counterproductive, becoming a source of a DoS vulnerability.

noob4lnx · 2022-09-24 18:40:57

mpan wrote:

Yes, it is absolutely possible. For example my tor.service is tweaked to get the score of 3.2, compared to landing in upper ranges by default.
The real question is however not if it’s possible, but if it’s needed. From the invocation to the way results are presented, `systemd-analyze security` is misleading in what it represents. It does not measure level of security or actual risk. What it does is estimating exposure, based on attack surfaces present. You can’t arbitrarily reduce exposure, because it is often inherent to the function of the service. The goal of reading `systemd-analyze security` should be primarily knowing the exposure, not aiming for nice numbers.
To make an analogy: by invoking `systemd-analyze security your-house` you would get poor score, because your house contains attack surfaces like windows and doors, and misses an underground bunker with 5 years supply of canned food. Obviously you do want to have doors and windows in your house, despite the risk, and probably can live without a bunker. Equally many services get poor score, because they must have some attack surfaces open to do their job.

It seems the default tor.service has a exposure of 6.6 (MEDIUM) so you did a good job. If you are willing to share your tor service file (assuming you installed Tor through pacman) I would like to try that one to harden one of the many service files.

I understand the exposure level from the 'systemd-analyze security' output says not much about objective security, as you already say its indeed just an indicator of relative attack surface the service is exposed to. I do wonder if the default services (listed above) are already security optimized. I know many of them like DBUS for example need a lot of 'attack surface exposure' just to function properly.

For many services it is possible to improve the situation, but that becomes tedious work, requiring understanding of what the process does, usually with little gains, but putting you at the risk of preventing the service from working. In particular upon an update. At some point improving `systemd-analyze security` rating may become counterproductive, becoming a source of a DoS vulnerability.

This is exactly my question as I don't think going through hours of testing per service using strace/ptrace and audit may be foolproof. Maybe securing third party apps like tor.service and self-created service files is the most feasible as for systemd hardening - assuming systemd default services are already optimized to max security/usability but this is only my guess (and the main question of this post).

Your tor indication of 3.2 is very very good. I still need to do mine. But if your is stable I would love to see what options brought it down to 3.2

noob4lnx · 2022-09-24 18:46:24

This is the default tor service file

# tor.service -- this systemd configuration file for Tor sets up a
# relatively conservative, hardened Tor service.  You may need to
# edit it if you are making changes to your Tor configuration that it
# does not allow.  Package maintainers: this should be a starting point
# for your tor.service; it is not the last point.

[Unit]
Description=Anonymizing overlay network for TCP
After=syslog.target network.target nss-lookup.target

[Service]
Type=notify
NotifyAccess=all
ExecStartPre=/usr/bin/tor -f /etc/tor/torrc --verify-config
ExecStart=/usr/bin/tor -f /etc/tor/torrc
ExecReload=/bin/kill -HUP ${MAINPID}
KillSignal=SIGINT
TimeoutSec=60
Restart=on-failure
WatchdogSec=1m
LimitNOFILE=32768

# Hardening
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH

[Install]
WantedBy=multi-user.target

Back to main question in case other people like to reply: I am curious for improving the default services like the ones below or perhaps someone can tell me this is not recommended at all:

dbus.service                              9.6 UNSAFE    ?
dm-event.service                          9.5 UNSAFE    ?
emergency.service                         9.5 UNSAFE    ?
getty@tty1.service                        9.6 UNSAFE    ?
rc-local.service                          4.1 OK        ?
rescue.service                            9.5 UNSAFE    ?
shadow.service                            9.6 UNSAFE    ?
systemd-ask-password-console.service      9.4 UNSAFE    ?
systemd-ask-password-wall.service         9.4 UNSAFE    ?
systemd-journald.service                  4.3 OK        ?
systemd-logind.service                    2.8 OK        ?
systemd-networkd.service                  2.6 OK        ?
systemd-resolved.service                  2.1 OK        ?
systemd-rfkill.service                    9.4 UNSAFE    ?

mpan · 2022-09-25 06:01:14

noob4lnx wrote:

If you are willing to share your tor service file (assuming you installed Tor through pacman) I would like to try that one to harden one of the many service files.

/etc/systemd/system/tor.service.d/override.conf:

[Service]
IPAddressAllow=127.0.0.0/31
IPAddressDeny=10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 127.0.0.0/24
ProtectProc=invisible
RestrictRealtime=true
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
ProtectKernelTunables=true
RestrictNamespaces=true
MemoryDenyWriteExecute=true
SystemCallArchitectures=native
ProtectKernelModules=true
ProtectControlGroups=true
ProtectKernelLogs=true
ProtectClock=true
ProtectHostname=true
SocketBindAllow=tcp:9001
SocketBindAllow=tcp:9030
SocketBindAllow=tcp:9050
SocketBindAllow=tcp:9051
SocketBindDeny=any
SystemCallFilter=~@clock
SystemCallFilter=~@cpu-emulation
SystemCallFilter=~@debug
SystemCallFilter=~@module
SystemCallFilter=~@obsolete
SystemCallFilter=~@reboot
SystemCallFilter=~@swap
SystemCallErrorNumber=EPERM

CPUAccounting=true
CPUQuota=100%
MemoryAccounting=true
MemoryHigh=800M
MemoryMax=1G

noob4lnx wrote:

assuming systemd default services are already optimized to max security/usability but this is only my guess (and the main question of this post).

They are not and it’s easy to see why. Network-facing services can’t have whitelist style network policies shipped with them, because it’s impossible to determine what the whitelist would be. Only the target system administrator can set those permissions up. That’s 0.2 penalty points. Any service that may potentially be configured to call or communicate with other programs must have the default policies permitting it — even in a particular deployment that feature is never used. And so on, and so on.

But, I will repeat it once more, do not chase the perfect score. Scores reflect your efforts being successful, but they should never be the goal. With the Tor service my train of though was like that:

I think I should check if I can improve that service?
What tool can I use to help me list potential attack surfaces.
`systemd-analyze` does exactly that.
I use `systemd-analyze security tor` to obtain the list I need, along with keywords to google for if I am unsure about a particular concern.

I do not deny that in future I may try to improve other services and I will use `systemd-analyze security` score to heuristically decide my priorities, so the decision will be driven by the score. Still, the entire process direction is “want to improve FOO → tool tells me about FOO” and not “tool tells me about FOO → want to improve FOO”.

Last edited by mpan (2022-09-25 06:19:05)

Arch Linux

#1 2022-09-23 22:26:44

[SOLVED] Is it possible to further Sandbox/Harden systemd services?

#2 2022-09-23 23:01:28

Re: [SOLVED] Is it possible to further Sandbox/Harden systemd services?

#3 2022-09-24 18:40:57

Re: [SOLVED] Is it possible to further Sandbox/Harden systemd services?

#4 2022-09-24 18:46:24

Re: [SOLVED] Is it possible to further Sandbox/Harden systemd services?

#5 2022-09-25 06:01:14

Re: [SOLVED] Is it possible to further Sandbox/Harden systemd services?

Board footer