Sdwdate worked fine but suddenly failed and refuses to start again, restart via GUI doesn’t work. This is under KVM.
whonix check results:
[ERROR] [systemcheck] Time Synchronization Result:
systemcheck gave up waiting.
journalctl -xe results:
https://web.archive.org/web/20220712110839/https://pst.klgrth.io/paste/zws9n
systemctl results:
user@host:~$ sudo systemctl status sdwdate.service
● sdwdate.service - Secure Distributed Web Date
Loaded: loaded (/lib/systemd/system/sdwdate.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/sdwdate.service.d
└─20_arch_syscall_whitelist.conf
Active: activating (auto-restart) (Result: core-dump) since Tue 2022-07-12 11:11:06 UTC; 1s ago
Docs: https://www.whonix.org/wiki/sdwdate
Process: 9017 ExecStart=/usr/libexec/sdwdate/sdwdate (code=dumped, signal=SYS)
Main PID: 9017 (code=dumped, signal=SYS)
CPU: 315ms
Jul 12 11:11:06 host systemd[1]: sdwdate.service: Main process exited, code=dumped, status=31/SYS
Jul 12 11:11:06 host systemd[1]: sdwdate.service: Failed with result 'core-dump'.
Jul 12 11:11:06 host systemd[1]: Failed to start Secure Distributed Web Date.
systemctl results:
user@host:~$ sudo systemctl start sdwdate.service
Job for sdwdate.service failed because a fatal signal was delivered causing the control process to dump core.
Sdwdate logs:
https://web.archive.org/web/20220712111359/https://pst.klgrth.io/paste/a6pjy
systemcheck --verbose --gui --cli results:
https://web.archive.org/web/20220712111629/https://pst.klgrth.io/paste/ot4z2
1 Like
Are you running on some “special” architecture or different virtualizer?
seccomp issue.
sdwdate.service: Scheduled restart job, restart counter is at 8.
SECCOMP auid=4294967295 uid=106 gid=116 ses=4294967295 subj==unconfined pid=1322 comm="sdwdate" exe="/usr/bin/python3.9" sig=31 arch=c000003e syscall=17 compat=0 ip=0x7866de236c6a code=0x80000000
audit: type=1326 audit(1657623304.243:34): auid=4294967295 uid=106 gid=116 ses=4294967295 subj==unconfined pid=1322 comm="sdwdate" exe="/usr/bin/python3.9" sig=31 arch=c000003e syscall=17 compat=0 ip=0x7866de236c6a code=0x80000000
sdwdate.service: Main process exited, code=dumped, status=31/SYS
syscall=17
Some user installed files seem to be in folder /usr/local/lib/python3.9.
Jul 12 10:59:53 host kernel: audit: type=1400 audit(1657623593.192:128): apparmor=“DENIED” operation=“open” profile=“/usr/bin/systemcheck” name=“/usr/local/lib/python3.9/dist-packages/cryptography/” pid=7133 comm=“tor-circuit-est” requested_mask=“r” denied_mask=“r” fsuid=109 ouid=0
I suppose this doesn’t happen in a newly installed Whonix?
This only happens if some custom software is installed without use of APT? Which custom software if I may ask?
I speculate what is happening is that the user is installing custom software which changes something around the python libs which are used at some point by systemcheck. The hardening of systemcheck does not recognize the changed syscalls and systemd therefore aborts when an unexpected seccomp syscall is received.
I am not sure yet how this should be fixed or if this should be fixed at all.
I installed some python libs via pip install and after experimenting did what systemcheck suggested and purged python3-pip, perhaps the purge removed a dependency?
Grepping through my history for the lib:
user@host:~$ history | grep "pip install"
52 pip install pypsrp
Ive since removed pypsrp however systemcheck yields the same errors.
No im using KVM and followed the guide here. My processor is AMD Ryzen 7.
Sdwdate log today:
sdwdate.service: Scheduled restart job, restart counter is at 790.
SECCOMP auid=4294967295 uid=106 gid=116 ses=4294967295 subj==unconfined pid=19737 comm="sdwdate" exe="/usr/bin/python3.9" sig=31 arch=c000003e syscall=17 compat=0 ip=0x79ea4c311c6a code=0x80000000
audit: type=1326 audit(1657798887.524:896): auid=4294967295 uid=106 gid=116 ses=4294967295 subj==unconfined pid=19737 comm="sdwdate" exe="/usr/bin/python3.9" sig=31 arch=c000003e syscall=17 compat=0 ip=0x79ea4c311c6a code=0x80000000
sdwdate.service: Main process exited, code=dumped, status=31/SYS
sdwdate.service: Failed with result 'core-dump'.
I cannot really provide help if custom software (installed by pip) changes the system’s default python libraries which then results in the systemd / seccomp hardening being broken.
I recommend a factory reset, re-installation method.
(Whonix is based on Kicksecure.)
Your only other options would be adding the required seccomp syscall as per: Debugging Systemd Seccomp
As for pip, please serach also for pip on this page:
Pip possibly previously installed lots of dependencies.