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.
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.
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.
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?
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).
/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.
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.
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 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.
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?
Could you remove please (not submit to)