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=rootand 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.
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.
Jul 01 08:11:15 host systemd[1]: /lib/systemd/system/whonixcheck.service:36: Failed to parse system call, ignoring: getresgud
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
user@host:~$Advice to debug SystemCallFilter=:
From https://github.com/systemd/systemd/issues/12974
sudo systemd-analyze log-level debugThe 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.
[Unit]
Description=whonixcheck
Documentation=https://www.whonix.org/wiki/whonixcheck
After=network.target
Wants=network.target
After=rinetd.service
After=tor.service
After=tor@default.service
After=onion-grater.service
After=whonix-firewall.service
After=whonix-firewall-sdwdate-watcher.service
Requires=msgcollector.service
[Service]
Type=simple
User=user
Group=user
ExecStart=/usr/lib/whonixcheckdaemon
SuccessExitStatus=143
#KillMode=process
TimeoutSec=30
Restart=always
# Hardening.
#ProtectSystem=strict
## ok
ProtectHome=true
## fail
#ProtectKernelTunables=true
## fail
#ProtectKernelModules=true
## ok
ProtectControlGroups=true
## ok
PrivateTmp=true
## ok
PrivateMounts=true
## fail
#PrivateDevices=true
## fail
#MemoryDenyWriteExecute=true
## fail
#NoNewPrivileges=true
## fail
#RestrictRealtime=true
## fail
#SystemCallArchitectures=native
## fail
#RestrictNamespaces=true
## 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
[Install]
WantedBy=multi-user.target
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.
The pam related changes didn’t do anything with sudo so I find it unlikely that they’re the reason for this.
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.
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?
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?
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.
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.