[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Apply systemd sandboxing by default to some services

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.

1 Like

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?

1 Like

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.

1 Like

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 https://chromium.googlesource.com/chromiumos/docs/+/master/constants/syscalls.md for a table to translate

140

to

_llseek

Platform dependent.

Maybe a better table:

https://marcin.juszkiewicz.com.pl/download/tables/syscalls.html

(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 https://github.com/Whonix/sdwdate/pull/29 - 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.
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallArchitectures=

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. :slight_smile:

Merged, and uploaded to Whonix developers repository.

1 Like

@Patrick finally got time to check onion-grater :slight_smile:

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
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]