This should work fine. The system call filter breaks the control port test so that’s commented out. Can anyone else test this? It works fine on my machine.
To test it, edit the service to run whonixcheck directly as root.
whonixcheck should not run as root. It is supposed to always run under
user whonixcheck (/usr/bin/whonixcheck does that) and to run sudo
by having /etc/sudoers.d/whonixcheck exceptions.
I guess you could probably create a systemd service to start that application then create a wrapper that runs systemctl start (application) that would then execute the program in a systemd sandbox. At this point though, it’d probably be better to use an alternative sandboxing method designed for applications like this.
Now, in Whonix 15, we have some really useful tools like systemd-analyze security which gives you an exposure score of systemd services. The lower the score, the better the sandboxing. You’ll see that the sandboxed services get really low scores (sdwdate is around 2 - 3) and the non-sandboxed services get really high scores (around 8 or 9).
The pam related changes most likely broke whonixcheck systemd hardening.
Jul 13 19:46:53 host whonixcheckdaemon[25502]: sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the ‘nosuid’ option set or an NFS file system without root privileges?
But even with the few enabled ones there is still an error message.
Jul 13 20:05:54 host PAM-CGFS[634]: cgroupfs v1: Failed to escape to init’s cgroup
Jul 13 20:05:54 host PAM-CGFS[634]: cgroupfs v1: Failed to enter cgroups
Jul 13 20:05:54 host PAM-CGFS[634]: Failed to enter user cgroup /user/root/0 for user root
I don’t think systemd hardening for whonixcheck is very important. It runs under user whonixcheck automatically anyhow. (/user/bin/whonixcheck does that.) And once users run whonixcheck manually it would not have systemd seccomp protections anyhow.
Therefore disabled in git master. Please retest and fix if you like.
I’m not sure that would be a good idea. The sandboxing removes all capabilities from kloak and it only works because the root user owns the devices kloak needs access to. Running it under a different user will make it so it doesn’t have permission to access those devices and we’ll need to give it the CAP_DAC_OVERRIDE capability which is dangerous as it allows it to bypass any DAC permission check. Any possible advantage to running it as a different user would mostly be lost.
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.