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!
1 Like
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.
1 Like
@Patrick opened fix systemd sandboxing for arm64 platform by GavinPacini · Pull Request #29 · Kicksecure/sdwdate · GitHub - this is working on arm64. Will handle onion-grater next.
2 Likes
Awesome!
Could you please try sudo systemctl restart sdwdate after it succeeded once? Because first time its sets time using date, subsequent ones using sclockadj. Therefore it might work the first time but break later due to missing secomp whiltelisted syscalls.
I am not also wondering if removing/changing SystemCallArchitectures setting would have been easier.
systemd.exec
Also generally wondering if SystemCallFilter is maintainable or will keep breaking when porting to the next version of Debian (bullseye) or other platforms.
Oh, good catch, sorry for not checking that.
Opened another PR which now also works after restarting the service.
1 Like
No worries.
This is hard to expect. 
Merged, and uploaded to Whonix developers repository.
1 Like
@Patrick finally got time to check onion-grater 
https://github.com/Whonix/onion-grater/pull/10/files
I did restart this a few time also. Anything else I should check?
1 Like
Awesome, no, this one is straight forward to test.
1 Like
@Patrick I realised that I missed one for sdwdate. The service started but the time never synched, now it does:
1 Like
Merged.
1 Like
We could create multiple arch-specific syscall whitelists to avoid bloating one whitelist with another’s syscalls and use a postinst script to detect the arch and enable the appropriate one.
2 Likes
Seems quite complex but if that’s maintained, then OK.
Could be something like the following in postinst:
arch="$(uname -m")
## Base syscalls. Suitable for x86.
syscall_whitelist="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 "
if [ "${arch}" =~ "arm64" ]; then
## ARM-specific syscalls.
syscall_whitelist+="readlinkat newfstatat mkdirat dup3 ppoll pselect6"
elif [ "${arch}" =~ "ppc" ]; then
## PowerPC-specific syscalls.
syscall_whitelist+="_llseek send waitpid recv prctl _newselect"
fi
str_replace "SystemCallFilter=" "SystemCallFilter=${syscall_whitelist}" /lib/systemd/system/sdwdate.service
1 Like