Another thing I think we should look into is creating device policies for our sandboxes so the service can only access a limited number of devices.
PrivateDevices=true sets up a new /dev mount and adds a few necessary devices like /dev/null and /dev/random but some services need access to more than just those (e.g. kloak needs access to input devices) so we can either just leave out PrivateDevices (less secure) or create a device policy so only the needed devices are in the sandbox (more secure).
Currently, we just leave out PrivateDevices but that isn’t great.
I haven’t had much luck with creating device policies though. The documentation is here.
sudo systemctl stop sdwdate also broken. Takes too long. Should be (almost) instant. Probably since the signal is no longer received by sdwdate. (Then systemd uses sigkill after timeout but that’s bad.)
sdwdate - ERROR - General Timeout Error. Internet connection might be down.
However, it appears regardless of whether or not the sandboxing is enabled. It only happens after I change the variable you told me to. Are you sure this is a sandboxing error and not a code error?
There was before no such code error. Cannot totally rule out yet but only happened after enabling sandboxing. I’ll see that I can provide instructions for reproduction.
I couldn’t reproduce this anymore. Perhaps I made a mistake and tested the wrong version. sdwdate sandboxing is re-enabled in Whonix developers, testers, and stable-proposed-updates repository.
Thank you for another great contribution!
sdwdate is getting killed on Debian buster on the ppc64el architecture.
How to debug systemd hardening? All I get:
sdwdate.service: Main process exited, code=killed, status=31/SYS
Any way to see a more specific error message which systemd hardening was violated? Any other way to debug other than trial and error which the offensive option is?