`Sandbox 1` in Tor 0.2.7.6 should not filter `getsockopt` syscall
In Tor version 0.2.7.6 (git-605ae665009853bd) on Debian sid, setting Sandbox 1 in torrc filters the getsockopt syscall, which is necessary for applications such as torsocks, xmpp-client, and TorBirdy. This syscall should be re-un-blacklisted from the seccomp policy. I say 're' because I confirmed it works in Debian Jessie running version 0.2.7.6-1~d80.jessie+1.
Trac:
Username: fowlslegs
Activity
changed milestone to %Tor: 0.2.8.x-final
Marking these as must-fix-before-028-rc.
Actually, some of them may not need to get 'fixed' before the rc, but I believe that they should either get fixed, or we should have a good explanation of why they don't need to get fixed.
Trac:
Keywords: getsockopt 027-backport deleted, getsockopt, 027-backport, must-fix-before-028-rc added-
Actually, we never stopped allowing getsockopt, but we do only allow some arguments to getsockopt. Grepping the code seems to suggest that we allow everything that
A stack trace would be really helpful here, or the final strace outputs before crash, or instructions on how to reproduce this bug. Has anybody else run into this?
Trac:
Status: new to needs_information
Reviewer: N/A to N/A -
Closed #18633 (moved) as a duplicate of this.
Spent a little bit of time looking at this... I'm a noob at debugging what's not in logs... so first I ran "tor &" in terminal from my normal user (I know not ideal but figured it'd give me an opportunity to check terminal for output) with "Sandbox 1" in torrc... and it started fine (no crash), and I checked /proc//status and indeed found "Seccomp: 2" indicating that seccomp filtering was enabled.
I tried the same with strace, but never encountered a crash. The problem only seems to occur when I try to start/restart the service using systemctl/systemd. Perhaps an issue with the unit file?
I was able to reproduce this issue with the following configuration:
OS: Ubuntu Server 16.04 64bits Minimal virtual machine install option chosen when installing (F4 menu). tor version: 0.2.7.6 (git-605ae665009853bd) Packages installed: tor apparmor-profiles apparmor-profiles-extra
Virtualization software: virtualbox 5.0.24 Host OS: Ubuntu Server 15.10 64bits
systemd uses the following command to start tor: /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 tor is started under user debian-tor
The only changes in the torrc config file where:
- enabling debug log
- adding Sandbox 1
Relevant files (tor-service-defaults-torrc, torrc and debug.log) are attached.
Trac:
strace-systemd.logTrac:
strace-console.logMore information:
As mentioned in the comments above, the issue only happens when starting the daemon with systemd. Running it on the console works fine.
I used strace to get a log of system calls from both the systemd started execution and the console started execution. I've attached both log files.
Execution seems similar until lines 1719 (console) and 1725 (systemd). From that point onwards, execution differs and soon we see the crash in the systemd execution.
The setsockopt call seen at line 1713 (console) and line 1719 (systemd) seems to be match the call on src/or/connection.c on line 1046.
Also, I am unable to reproduce the problem when I compile this version (compiled from git tag tor-0.2.7.6) on the affected machine. The newly compiled binary runs fine when started by systemd. Only the binary that comes with Ubuntu crashes.
I figured it out.
Notice that in my last post, the line numbers of the strace logs show a 6 line mismatch between the console and the systemd execution. I tracked this difference down to lines 253 to 259 in the systemd execution:
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3 getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) setsockopt(3, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0 @default.service: Supervising process 25665 which is not our child. We'll most likely not notice when it exits. sendmsg(3, {msg_name(21)={sa_family=AF_LOCAL, sun_path="/run/systemd/notify"}, msg_iov(1)=[{"MAINPID=25665\n", 14}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 14 close(3) = 0These lines are missing in the console execution. They belong to the systemd sd_notify call.
Now notice the last lines before the crash in the systemd execution:
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 11 syscall_18446744073709551615(0xb, 0x1, 0x7, 0x7fff259b7e40, 0x7fff259b7e44, 0xb) = 0x37 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x7f9107f2492a, si_syscall=__NR_getsockopt, si_arch=AUDIT_ARCH_X86_64} ---This is again, the sd_notify call from systemd. It crashed on the second line. This line is trying to call getsockopt with the first argument being the socket created in the first line, the second argument SOL_SOCKET and the third SO_SNDBUF, just like we seen before.
I suspect the reason it crashed now and not before is because the seccomp filter still wasn't setup when sd_notify was first called.
Also I suspect that when I built from source, I failed to build with systemd support and that must be the reason why it did not crash.
I was able to modify the code to add the calls introduced by systemd sd_notify to the seccomp filter. Now tor crashed further ahead with another bad syscall error, this time trying to call sysinfo. The new crash happens both in the console and systemd started executions.
I'll submit a patch once I get tor starting with Sandbox enabled.
I've written the patch. It is available on github:
https://github.com/Jigsaw52/tor/tree/seccomp-fix-18397
The patch changes the sandbox filter to allow the following when built with systemd:
- getsockopt with SOL_SOCKET and SO_SNDBUF as arugments
- setsockopt with SOL_SOCKET and SO_SNDBUFFORCE
This calls are used by the systemd sd_notify function.
It also allows the sysinfo syscall as the libc qsort function uses it.
Trac:
Status: needs_information to needs_review
Patch looks good. I also confirm that it builds correctly and chutney test passes.
@nickm: The current commit conflicts with master but trivial fix.
Trac:
Status: needs_review to merge_ready
Reviewer: N/A to dgouletmentioned in issue #18633 (moved)
moved to tpo/core/tor#18397 (closed)