Apply systemd sandboxing by default to some services

No, PrivateHome=true and PrivateTmp=true both work fine. Everything else doesn’t. Even things that are very unlikely to break things.

I found the issue. The way the service is configured seemed to be hiding the actual error message which was

sudo: effective uid is not 0

So I added user=root and now it works. All the sandboxing seems fine except the syscall filter which I’ll work on now.


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.

madaidan via Whonix Forum:

So I added user=root and now it works.

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.

Running as root fortifies advice given

Yes, I know. Running it as root is only for testing as running it directly with a systemd service as a user fails.

1 Like

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.

1 Like

Jul 01 08:11:15 host systemd[1]: /lib/systemd/system/whonixcheck.service:36: Failed to parse system call, ignoring: getresgud

1 Like

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).


brilliant tool, this is the test runs on whonix 15 ws in Qubes:

UNIT                                                                                                 EXPOSURE PREDICATE
anon-ws-disable-stacked-tor.service                                                                       9.1 UNSAFE   
anon-ws-disable-stacked-tor_autogen__var_run_anon-ws-disable-stacked-tor_127.0.0.1_9050.sock.service      9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen__var_run_anon-ws-disable-stacked-tor_127.0.0.1_9051.sock.service      9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen__var_run_anon-ws-disable-stacked-tor_127.0.0.1_9150.sock.service      9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen__var_run_anon-ws-disable-stacked-tor_127.0.0.1_9151.sock.service      9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen__var_run_anon-ws-disable-stacked-tor_127.0.0.1_9152.sock.service      9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen__var_run_anon-ws-disable-stacked-tor_127.0.0.1_9153.sock.service      9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen__var_run_tor_control.service                                          9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen__var_run_tor_socks.service                                            9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen_port_11109.service                                                    9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen_port_9050.service                                                     9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen_port_9051.service                                                     9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen_port_9150.service                                                     9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen_port_9151.service                                                     9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen_port_9152.service                                                     9.2 UNSAFE   
anon-ws-disable-stacked-tor_autogen_port_9153.service                                                     9.2 UNSAFE   
cron.service                                                                                              9.5 UNSAFE   
dbus.service                                                                                              9.5 UNSAFE   
emergency.service                                                                                         9.5 UNSAFE   
getty@tty1.service                                                                                        9.5 UNSAFE   
getty@ttyUSB0.service                                                                                     9.5 UNSAFE   
haveged.service                                                                                           5.6 MEDIUM   
jitterentropy.service                                                                                     9.5 UNSAFE   
polkit.service                                                                                            9.5 UNSAFE   
qubes-db.service                                                                                          9.5 UNSAFE   
qubes-firewall.service                                                                                    9.5 UNSAFE   
qubes-gui-agent.service                                                                                   9.5 UNSAFE   
qubes-meminfo-writer.service                                                                              9.5 UNSAFE   
qubes-qrexec-agent.service                                                                                9.5 UNSAFE   
qubes-sync-time.service                                                                                   9.5 UNSAFE   
qubes-updates-proxy.service                                                                               9.5 UNSAFE   
qubes-whonix-redirect-9050.service                                                                        9.2 UNSAFE   
rc-local.service                                                                                          9.5 UNSAFE   
rescue.service                                                                                            9.5 UNSAFE   
rsync.service                                                                                             9.5 UNSAFE   
rsyslog.service                                                                                           9.5 UNSAFE   
sdwdate.service                                                                                           2.8 OK       
serial-getty@hvc0.service                                                                                 9.5 UNSAFE   
serial-getty@ttyAMA0.service                                                                              9.5 UNSAFE   
serial-getty@ttyO0.service                                                                                9.5 UNSAFE   
serial-getty@ttyO2.service                                                                                9.5 UNSAFE   
serial-getty@ttyS0.service                                                                                9.5 UNSAFE   
serial-getty@ttymxc0.service                                                                              9.5 UNSAFE   
serial-getty@ttymxc3.service                                                                              9.5 UNSAFE   
sysfsutils.service                                                                                        9.5 UNSAFE   
systemd-ask-password-console.service                                                                      9.3 UNSAFE   
systemd-ask-password-wall.service                                                                         9.3 UNSAFE   
systemd-fsckd.service                                                                                     9.5 UNSAFE   
systemd-initctl.service                                                                                   9.3 UNSAFE   
systemd-journald.service                                                                                  4.3 OK       
systemd-logind.service                                                                                    4.1 OK       
systemd-networkd.service                                                                                  2.8 OK       
systemd-timesyncd.service                                                                                 2.0 OK       
systemd-udevd.service                                                                                     8.3 EXPOSED  
tinyproxy.service                                                                                         8.7 EXPOSED  
tor@default.service                                                                                       6.3 MEDIUM   
udisks2.service                                                                                           9.5 UNSAFE   
user@1000.service                                                                                         9.1 UNSAFE   
virtualbox-guest-utils.anondist.service                                                                   9.5 UNSAFE   
whonix-firewall-restarter.service                                                                         9.5 UNSAFE   
whonixcheck.service                                                                                       9.1 UNSAFE   
wpa_supplicant.service                                                                                    9.5 UNSAFE   
xendriverdomain.service                                                                                   9.5 UNSAFE   
1 Like

Advice to debug SystemCallFilter=:

From https://github.com/systemd/systemd/issues/12974

sudo systemd-analyze log-level debug

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?

To test:

sudo systemctl daemon-reload && sudo systemctl restart whonixcheck && sleep 1 && sudo systemctl status whonixcheck.service | cat

Again “most” of them don’t work. List below.

## Copyright (C) 2012 - 2018 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>
## See the file COPYING for copying conditions.






# Hardening.

## ok

## fail

## fail

## ok

## ok

## ok

## fail

## fail

## fail

## fail

## fail

## fail

## fail
#RestrictAddressFamilies=AF_UNIX AF_INET

## fail
#SystemCallFilter=wait4 read close execve open write rt_sigprocmask stat munmap mprotect clone mmap fstat access brk poll rt_sigaction select ioctl recvfrom getuid getgid getegid pipe getpid futex arch_prctl lseek rt_sigreturn geteuid fcntl getdents dup2 readlink sync getsid unlink sysinfo uname connect setresuid lstat newfstatat sendto getrlimit statfs faccessat sendmsg getppid setgroups bind umask fchmod writev mremap msync madvise dup alarm socket recvmsg shutdown getsockname getpeername socketpair getsockopt setsockopt kill getcwd chdir fchdir rename mkdir chmod chown lchown getrusage setuid setgid setpgid getpgrp setsid getgroups getresuid setresgid getresgid getpgid capget sigaltstack fstatfs prctl setrlimit gettid getxattr sched_getaffinity set_tid_address fadvise64 timer_create timer_settime openat unlinkat fchmodat ppoll set_robust_list utimensat getrandom


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.

1 Like

The pam related changes didn’t do anything with sudo so I find it unlikely that they’re the reason for this.

1 Like
1 Like

Doesn’t kloak already run as a privleged process? By definition of its function it needs to access the input device.

That doesn’t mean it can’t be sandboxed. It’s actually more of a reason to sandbox it.

The sandboxing doesn’t restrict access to any devices.

1 Like

Yeah. The original systemd unit file has certainly room for improvement.

Maybe it could/should even run under a limited user account kloak.

If you want to do that too…

Btw please consider Port to sysusers.d mechanism?

1 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.


Members of group input are allowed to write to /dev/input devices. So user kloak could be a member of group /dev/input.

ls -la /dev/input/

crw-rw---- 1 root input
crw-rw---- 1 root input

By being a member of the input group no CAP_DAC_OVERRIDE capability would be required?

1 Like

Kloak doesn’t actually write to /dev/input. It writes to /dev/uinput.

At least, that’s what it says when starting it

* Started kloak : Keystroke-level Online Anonymizing Kernel
* Reading from  : /dev/input/event5 (dakai PS/2+USB Keyboard)
* Writing to    : /dev/uinput
* Maximum delay : 100 ms

/dev/uinput isn’t owned by the input group. It’s owned by the root group.

ls -la /dev/uinput

crw------- 1 root root

It seems like we can change what group it’s owned by with a udev rule so we can probably make it owned by the kloak group.

1 Like

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.

Debian doesn’t seem to use this much. Running

grep "DeviceAllow" /lib/systemd/system/*.service

only shows OpenVPN stuff.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]