[tor-bugs] #18397 [Core Tor/Tor]: `Sandbox 1` in Tor 0.2.7.6 should not filter `getsockopt` syscall

[Tor Bug Tracker & Wiki]

#18397: `Sandbox 1` in Tor 0.2.7.6 should not filter `getsockopt` syscall
-------------------------------------------------+-------------------------
 Reporter:  fowlslegs                            |          Owner:  nickm
     Type:  defect                               |         Status:
 Priority:  High                                 |  needs_information
Component:  Core Tor/Tor                         |      Milestone:  Tor:
 Severity:  Major                                |  0.2.???
 Keywords:  seccomp, sandbox, getsockopt,        |        Version:  Tor:
  027-backport                                   |  0.2.7.6
Parent ID:                                       |     Resolution:
 Reviewer:                                       |  Actual Points:
                                                 |         Points:
                                                 |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by Jigsaw52):

 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)                                = 0
 }}}

 These 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 am guessing the reason it crashed now and not before is because the
 seccomp filter still wasn't setup when sd_notify was first called.

 This also explains why I wasn't able to reproduce the crash with the
 version compiled from source: I was using the original tor source which is
 missing the sd_notify calls introduced in the Ubuntu modified version.

 So this bug was introduced by the Debian modifications to integrate tor
 with systemd.

 ----

 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 suspect this new problem is caused by Debian modifications but further
 investigation is needed.

 I'll submit a patch to Ubuntu and Debian once I get tor starting with
 Sandbox enabled.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18397#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online