[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Apply systemd sandboxing by default to some services

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: https://trac.torproject.org/projects/tor/ticket/20930

2 Likes

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

2 Likes

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:

2 Likes

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.

2 Likes

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?

2 Likes

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

Could you please /lib/systemd instead? (as per https://www.whonix.org/wiki/Dev/About_Debian_Packaging#Modifying_Default_Configuration_of_Third_Party_Packages)

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.

2 Likes

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 https://github.com/madaidan/security-misc/commit/66b99b974355328095b8eb9292632bdf46805645

2 Likes

madaidan via Whonix Forum:

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.

I think you mean the other way round?

Yes.

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.

I just fixed that. See https://github.com/madaidan/security-misc/commit/66b99b974355328095b8eb9292632bdf46805645

Awesome!

1 Like

madaidan via Whonix Forum:

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

https://github.com/madaidan/onion-grater/commit/f0312d95bc721580088a10c4230ab10ff97f30f9

Not working for me, answered here:

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

1 Like

Just removed it.

How would I test this?

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

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

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


please?

2 Likes

I’ve created a pull request for sdwdate.

I still need to create a syscall whitelist for it.

1 Like

Merged.

1 Like

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

1 Like

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.

2 Likes

madaidan via Whonix Forum:

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?

2 Likes

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.

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

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.

1 Like