Great guides for using systemd to sandbox services. There may be features in there beyond what we do:
https://github.com/Whonix/onion-grater/pull/9
We should look into setting a more restrictive umask per-service (not global like we tried before) and whitelisting IP addresses.
Umask=0077
IPAddressDeny=any
IPAddressAllow=...
I tried these but it broke onion-grater. Exactly which IP addresses does onion-grater connect to? We can create a whitelist of them.
Is disable systemd hardening Ā· Kicksecure/sdwdate@b5f0ea1 Ā· GitHub still a problem? I canāt reproduce it with the sandboxing enabled. I can send a PR to strengthen sdwdateās sandboxing too if that isnāt an issue anymore.
I see no issues on my end. Please test.
I had to remove MemoryDenyWriteExecute
from onion-grater and sdwdate because some python thing seems to be using RWX memory for some reason.
You may get these errors:
Unknown lvalue 'ProtectKernelLogs' in section 'Service', ignoring
Unknown lvalue 'ProtectHostname' in section 'Service', ignoring
Unknown lvalue 'ProtectProc' in section 'Service', ignoring
Unknown lvalue 'ProcSubset' in section 'Service', ignoring
These are harmless. Those options only exist in later versions of systemd but I added them for forward compatibility. Another option to look into: https://github.com/systemd/systemd/commit/407234203b41e0a27b3229347c1ad6b2b17e3c21
All merged.
Awesome! I will test this over the next days and report back should there be any issues.
Broken.
sdwdate log will show:
/bin/date: cannot set date: Operation not permitted
During testing might help:
sudo sdwdate-clock-jump
sudo systemctl restart sdwdate
First sets time using date
. The later (after first time after boot setting using date
) using sclockadj
.
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.)
Try adding kill getsockopt unlink
to SystemCallFilter
, /var/lib/sdwdate/
to ReadWriteDirectories
and commenting PrivateUsers
.
## Sandboxing.
AmbientCapabilities=CAP_SYS_TIME
CapabilityBoundingSet=CAP_SYS_TIME
ProtectSystem=strict
ReadWriteDirectories=/run/sdwdate/ /var/lib/sdwdate/
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
ProtectKernelLogs=true
ProtectHostname=true
ProtectProc=invisible
ProcSubset=pid
PrivateTmp=true
#PrivateUsers=true
PrivateDevices=true
NoNewPrivileges=true
LockPersonality=true
RestrictRealtime=true
RestrictSUIDSGID=true
RestrictAddressFamilies=AF_UNIX AF_INET
RestrictNamespaces=true
SystemCallFilter=wait4 select futex read stat close openat fstat lseek mmap rt_sigaction getdents64 mprotect ioctl recvfrom munmap brk rt_sigprocmask fcntl getpid write access socket sendto dup2 clone execve getrandom geteuid getgid madvise getuid getegid readlink pipe rt_sigreturn connect pipe2 prlimit64 set_robust_list dup arch_prctl lstat set_tid_address sysinfo sigaltstack rt_sigsuspend shutdown timer_settime mkdir timer_create statfs getcwd setpgid setsockopt uname bind getpgrp getppid getpeername chdir poll getsockname fadvise64 clock_settime kill getsockopt unlink
SystemCallArchitectures=native
Does that fix the issue?
That works better. However one issue remains. remote_times.py
process.wait(timeout_seconds)
is broken. Hangs forever. To reproduce, try this:
File:
/usr/lib/python3/dist-packages/sdwdate/remote_times.py
change
timeout_seconds = 120
to
timeout_seconds = 2
And then restart sdwdate.
Meanwhile I will revert these changes to unbreak sdwdate in Whonix developers repository. Once this is fixed, Iāll look into it ASP.
Iām getting this error:
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?
Similar issue:
Got an answer on reddit.
sudo journalctl _AUDIT_TYPE_NAME=SECCOMP -f
May 05 06:29:26 whonix1 audit[9740]: SECCOMP auid=4294967295 uid=108 gid=118 ses=4294967295 subj==/usr/bin/sdwdate (enforce) pid=9740 comm=āsdwdateā exe=ā/usr/bin/python3.7ā sig=31 arch=c0000015 syscall=140 compat=0 ip=0x7fff96cc7df4 code=0x0
Found Chromium OS Docs - Linux System Call Table for a table to translate
140
to
_llseek
Platform dependent.
Maybe a better table:
Linux system calls table for several architectures
(Replace sdwdate
with the systemd unit name to debug.)
sudoedit /lib/systemd/system/sdwdate.service && sudo systemctl daemon-reload && sudo systemctl restart sdwdate && sudo systemctl --no-page status sdwdate
This is great, I will already try the new SystemCallFilter, and if it does not work on arm64, Iāll follow your debug steps and open a PR.