Hi everyone,
Ever since I upgraded to tor version 0.4.5.6, enabling tor's built-in seccomp sandbox completely breaks tor, i.e. it gets killed by the kernel on start for a seccomp violation (fstat(..)) - sandboxing worked fine on 0.4.4.6, my system configuration did not change between the updates.
Not specifying 'Sandbox 1' in the torrc allows tor to fully start as usual, I had to disable it post-update in order to be able to continue running my relay.
/etc/tor/torrc:
ORPort 37.157.195.83:38619 ORPort [2a02:2b88:2:1::3239:0]:38619 Nickname michaelscott ContactInfo ttallink@googlemail.com ControlPort 9051 SocksPort 0 CookieAuthentication 1 ExitPolicy reject *:* DataDirectory /var/lib/tor # Sandbox 1 ShutdownWaitLength 120 MaxMemInQueues 672MB
/usr/lib/systemd/system/tor.service:
[Unit] Description=Anonymizing Overlay Network After=network.target
[Service] User=tor Type=simple ExecStart=/usr/bin/tor -f /etc/tor/torrc ExecReload=/usr/bin/kill -HUP $MAINPID KillSignal=SIGINT LimitNOFILE=32768 PrivateDevices=yes
[Install] WantedBy=multi-user.target
/etc/systemd/system/tor.service.d/override.conf:
[Service] PrivateTmp=yes ProtectHome=yes ProtectSystem=strict ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectControlGroups=yes NoNewPrivileges=yes RestrictSUIDSGID=yes RestrictAddressFamilies=AF_INET AF_INET6 ReadWritePaths=/var/lib/tor CapabilityBoundingSet=CAP_NET_BIND_SERVICE TimeoutStopSec=2min 15s
I'm running ArchLinux with the 5.11.4 kernel, Tor is still sandboxed by systemd so this is not a huge issue but I would like to be able to continue using the built-in sandbox as well as systemd's sandboxing options in order to maximize process isolation.
Did anyone else run into this?
I would have posted a bug report but due to various reason I am not able to do so right now.
I figured this was happening because I do not grant the CAP_DAC_READ_SEARCH capability, but I'm not so sure anymore if that's the reason.
Any help is greatly appreciated.
- William
Hi William
William Kane:
Hi everyone,
Ever since I upgraded to tor version 0.4.5.6, enabling tor's built-in seccomp sandbox completely breaks tor, i.e. it gets killed by the kernel on start for a seccomp violation (fstat(..)) - sandboxing worked fine on 0.4.4.6, my system configuration did not change between the updates.
Tor itself usually fails with a Permission Denied error when a syscall fails due to seccomp. So, this is rather odd.
I figured this was happening because I do not grant the CAP_DAC_READ_SEARCH capability, but I'm not so sure anymore if that's the reason.
You should simply see a Permission Denied if the capability is the problem.
Would be great if you could get details about the failing call. If seccomp is involved, you should be able to get details like this:
• install package auditd • make sure auditd is running • crash Tor • find the syscall with `ausearch -ts recent -i`
Peter
tor-relays@lists.torproject.org