Apply systemd sandboxing by default to some services

madaidan · June 21, 2019, 5:31pm

Systemd has a few features that allow you to sandbox systemd services to prevent the damage that a compromised service could do.

It would be good to apply some sandboxing by default to some services. A lot of settings like PrivateTmp=true and PrivateHome=true can be set for most services without breaking anything.

I can create some sandboxes and test them for a few services if needed. They could probably be placed in security-misc.

A related Tor ticket: Use new systemd hardening options (#20930) · Issues · Legacy / Trac · GitLab

HulaHoop · June 22, 2019, 3:59am

Sounds good. Network facing services are a good place to start

Patrick · June 22, 2019, 7:14am

Such patches should be submitted upstream to the original developer (when they are open to having a systemd unit file or at least already have a systemd unit file), as well as submitted upstream to Debian. This is very important to:

offload maintenance work in the long run,
inspire them to play around adding more systemd sandboxing (they understand their software better than we do),
and to have them run into bugs first in case their software changes so we don’t run into these bugs on (distribution) upgrades.

Additionally we could add to security-misc, so how that goes (if too many issues, a separate package) but only after above is done as a stopgap until upstream flows down to Whonix.

You could start with Whonix’s own (network facing priority) systemd unit files, which of course can be quickly merged in Whonix itself.

Related Whonix tickets:

systemd-analyze security

madaidan · June 22, 2019, 1:15pm

I’m creating some here and I’m currently working on a sdwdate sandbox. It’s a bit hard as Debian uses a very old version of systemd that doesn’t have many of the debugging tools.

madaidan · June 22, 2019, 2:24pm

I just fixed the onion-grater hardening (I hope).

It doesn’t seem to work on the workstation for me when I try to get a new identity with the TorButton but I don’t know if that’s because of some other modifications I did a while ago or if it’s because it’s broken. Can someone else test this?

Patrick · June 22, 2019, 3:43pm

New identity works for me generally. Will test soon with the hardening enabled.

Could you please /lib/systemd instead? (as per Dev/About Debian Packaging - Kicksecure)

https://github.com/madaidan/security-misc/blob/patch-4/etc/systemd/system/whonix-firewall.service.d/sandbox.conf → this should be merged into https://github.com/Whonix/whonix-firewall/blob/master/lib/systemd/system/whonix-firewall.service directly. But before that, see below…

Why is https://github.com/madaidan/security-misc/blob/patch-4/etc/systemd/system/whonix-firewall.service.d/sandbox.conf needed at all? What’s the threat model here? It’s just a bash script / config / iptables rules being load. No interaction with any remote servers. How would the firewall script be exploited? For that script I’d wish to have a strong rationale since the risk of systemd blocking the loading of firewall rules seems more risky than the exploitation risk (for a yet to be described threat model).

https://github.com/madaidan/security-misc/blob/patch-4/etc/systemd/system/dbus.service.d/sandbox.conf → /lib/systemd please and submit upstream please as well.

https://github.com/Whonix/sdwdate/blob/master/lib/systemd/system/sdwdate.service - this can go directly to https://github.com/madaidan/security-misc/blob/patch-4/etc/systemd/system/sdwdate.service.d/sandbox.conf.

Paths to also add:

/usr/local/etc/onion-grater-merger.d
/usr/local/etc/sdwdate.d (does not exist yet but should and will be added at some point)
/usr/local/etc/ generally for any package by Whonix probably already exist or will be added

ReadWriteDirectories=/var/run/sdwdate/ /var/log/

This is good enough for merge (improvement) but non-perfect to allow all of /var/log/. Possible to hardcode to /var/log/sdwdate.log or otherwise we could move everything (“grep Whonix source code”) to /var/log/sdwdate/sdwdate.log.

madaidan · June 22, 2019, 4:04pm

I’ve moved them all to /lib/systemd. I’m used to using /etc/systemd instead so I used that the first time.

There is no specific reason. I just thought it might be good to sandbox it.

It could be removed or I could trim it a bit so it will clearly not mess with the loading of the firewall rules.

I think you mean the other way round?

These likely won’t need to be added. The sandboxing doesn’t make all directories inaccessible but makes them read-only. Configuration files usually aren’t written to by the service.

I just fixed that. See Only allow access to sdwdate.log rather than all of /var/log · madaidan/security-misc@66b99b9 · GitHub

Patrick · June 23, 2019, 7:14am

madaidan via Whonix Forum:

Patrick:

For that script I’d wish to have a strong rationale since the risk of systemd blocking the loading of firewall rules seems more risky than the exploitation risk

It could be removed or I could trim it a bit so it will clearly not mess with the loading of the firewall rules.

Please remove.

Patrick:

https://github.com/Whonix/sdwdate/blob/master/lib/systemd/system/sdwdate.service - this can go directly to https://github.com/madaidan/security-misc/blob/patch-4/etc/systemd/system/sdwdate.service.d/sandbox.conf.

I think you mean the other way round?

Yes.

Patrick:

Paths to also add:

/usr/local/etc/onion-grater-merger.d

/usr/local/etc/sdwdate.d (does not exist yet but should and will be added at some point)

/usr/local/etc/ generally for any package by Whonix probably already exist or will be added

These likely won’t need to be added. The sandboxing doesn’t make all directories inaccessible but makes them read-only. Configuration files usually aren’t written to by the service.

Alright, could you please test if /usr/local/etc/onion-grater-merger.d
is still functional? This is actually used in Qubes-Whonix. Applications
needing an onion-grater profile are using that location by default in
Whonix documentation.

Patrick:

This is good enough for merge (improvement) but non-perfect to allow all of /var/log/ . Possible to hardcode to /var/log/sdwdate.log or otherwise we could move everything (“grep Whonix source code”) to /var/log/sdwdate/sdwdate.log .

I just fixed that. See Only allow access to sdwdate.log rather than all of /var/log · madaidan/security-misc@66b99b9 · GitHub

Awesome!

Patrick · June 23, 2019, 8:28am

madaidan via Whonix Forum:

I just fixed the onion-grater hardening (I hope).

Fix systemd hardening · madaidan/onion-grater@f0312d9 · GitHub

Not working for me, answered here:

https://phabricator.whonix.org/T631#18614

madaidan · June 23, 2019, 1:53pm

Just removed it.

How would I test this?

Seems it needs the openat syscall. I’ll try and fix it now.

madaidan · June 23, 2019, 2:08pm

I’ve added /usr/local/etc/onion-merger.d just in case.

Patrick · June 23, 2019, 6:04pm

sdwdate working! Could you remove please (not submit to)
security-misc and add to

github.com

Kicksecure/sdwdate/blob/master/lib/systemd/system/sdwdate.service

## Copyright (C) 2012 - 2022 ENCRYPTED SUPPORT LP <adrelanos@whonix.org>
## See the file COPYING for copying conditions.

## similar file by package apparmor-profile-everything (AAE):
## /lib/systemd/system/sdwdate-aae.service

[Unit]
Description=Secure Distributed Web Date
Documentation=https://www.whonix.org/wiki/sdwdate
ConditionPathExists=!/run/qubes/this-is-templatevm
ConditionPathExists=!/run/qubes-service/no-sdwdate

## systemd-nspawn does not allow clock to be changed inside the container.
## Quote https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
## The host's network interfaces and the system clock may not be changed from within the container.
## https://forums.whonix.org/t/bootclockrandomization-always-moving-clock-plus-or-5-seconds/2200/10
ConditionVirtualization=!systemd-nspawn

After=network.target
Wants=network.target

This file has been truncated. show original

please?

madaidan · June 23, 2019, 6:15pm

I’ve created a pull request for sdwdate.

I still need to create a syscall whitelist for it.

Patrick · June 23, 2019, 6:23pm

Merged.

Patrick · June 25, 2019, 6:32am

https://github.com/Whonix/whonixcheck/pull/10

Not tested yet. Did you test with whonixcheck --leak-tests --gui --cli --verbose --debug too?

madaidan · June 25, 2019, 7:07pm

I just tested that and it works fine. I’m not sure if that would be sandboxed by systemd though as it isn’t started by whonixcheck.service but by the user.

Patrick · June 26, 2019, 7:08am

madaidan via Whonix Forum:

Patrick:

Not tested yet. Did you test with whonixcheck --leak-tests --gui --cli --verbose --debug too?

I just tested that and it works fine. I’m not sure if that would be sandboxed by systemd though as it isn’t started by whonixcheck.service but by the user.

Indeed.

Can we make (systemd|seccomp|…) hardening also work with manual
invocations?

madaidan · June 26, 2019, 1:04pm

I don’t think that’s possible.

I’ll try to edit the systemd service to run the whonixcheck command directly to see if it works.

madaidan · June 26, 2019, 1:28pm

Making the service run whonixcheck directly breaks when I use more than PrivateHome=true and PrivateTmp=true which is really weird.

Patrick · June 26, 2019, 1:45pm

madaidan via Whonix Forum:

Making the service run whonixcheck directly breaks when I use more than PrivateHome=true and PrivateTmp=true which is really weird.

It’s maybe because folder ~/ is open when typing in terminal.