Opened 7 years ago

Closed 7 years ago

#11477 closed defect (fixed)

Make --enable-expensive-hardening work with sandbox

Reported by: nickm Owned by: nickm
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay 025-triaged 025-deferrable
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

We should encourage people to build, sometimes, with more expensive hardening options than we'd like by default. I'm thinking in particular of turning on AddressSanitizer where available.

This should also force memory pool optimizations off, if they're not already off by default. (see #11476)

The above is merged; see discussion below for the remaining parts of this ticket.

Child Tickets

Attachments (1)

tor-0.2.4.21-as.patch (2.6 KB) - added by nickm 7 years ago.
patch from 'starlight' on tor-talk

Download all attachments as: .zip

Change History (16)

comment:1 Changed 7 years ago by nickm

Status: newneeds_review

Branch "bug11477" contains a quick implementation here.

Changed 7 years ago by nickm

Attachment: tor-0.2.4.21-as.patch added

patch from 'starlight' on tor-talk

comment:2 Changed 7 years ago by nickm

I've attached a separate patch from starlight on tor-relays (see "running Tor relay live with AddressSanitizer") that redirects stdout and stderr instead of closing them, and which uses __sanitizer_sandbox_on_notify() to work well with chroot and other sandboxen.

This should be conditional on AddressSanitizer being enabled. Perhaps __sanitizer_sandbox_on_notify() also needs to be integrated with our seccomp2 sandboxing. Needs testing.

comment:3 Changed 7 years ago by nickm

I wonder if __sanitizer_set_report_fd() isn't a better idea than "tor.out" and "tor.err" replacing stdout and stderr.

comment:4 Changed 7 years ago by nickm

Keywords: nickm-review-0254 added

comment:5 Changed 7 years ago by nickm

Keywords: tor-relay added; nickm-review-0254 removed
Owner: set to nickm
Status: needs_reviewassigned

I've merged the "bug11477" branch after some testing; this ticket is now about integrating starlight's patch above.

comment:6 Changed 7 years ago by nickm

Description: modified (diff)
Summary: Add an --enable-expensive-compiler-hardening optionMake --enable-expensive-compiler-hardening work with sandbox

comment:7 Changed 7 years ago by nickm

Keywords: 025-triaged 025-deferrable added

Leaving in 0.2.5, since I think that people who are extra paranoid will probably want to try both of these features together. If it turns out to be a huge yak-shaving exercise, though, it waits for 0.2.6.

comment:8 Changed 7 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

In my experiments, this mostly worked, except that if there's an error message from the sanitizer, you get a sandbox failure stack trace from inside the sandbox rather than a sanitizer message and stack trace. I think that's deferrable.

comment:9 in reply to:  8 Changed 7 years ago by alphawolf

Replying to nickm:

In my experiments, this mostly worked, except that if there's an error message from the sanitizer, you get a sandbox failure stack trace from inside the sandbox rather than a sanitizer message and stack trace. I think that's deferrable.

I got a stack trace at 'Bootstrapped 80%' using 0.2.5.4-alpha-dev. I did not apply starlight's patch. Is this expected? (You said it "mostly worked"). Do you want the stack trace and/or a new bug report?

Also, I didn't see a configure option called --enable-expensive-compiler-hardening. I assume this is actually --enable-expensive-hardening?

comment:10 Changed 7 years ago by nickm

Summary: Make --enable-expensive-compiler-hardening work with sandboxMake --enable-expensive-hardening work with sandbox

Do you want the stack trace and/or a new bug report?

Yes please!

I assume this is actually --enable-expensive-hardening?

That's right.

comment:11 Changed 7 years ago by alphawolf

Note, this is built from the nickm bug11946 branch:

May 14 19:32:00.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed 4C8387D56221185ABE68E4BDF6E164BF759B4F52'
May 14 19:32:00.000 [notice] Bootstrapped 0%: Starting
May 14 19:32:00.000 [notice] This version of Tor (0.2.5.4-alpha-dev) is newer than any recommended version, according to the directory authorities. Recommended versions are: 0.2.3.24-rc,0.2.3.25,0.2.4.17-rc,0.2.4.18-rc,0.2.4.19,0.2.4.20,0.2.4.21,0.2.4.22,0.2.5.1-alpha,0.2.5.2-alpha,0.2.5.3-alpha,0.2.5.4-alpha
May 14 19:32:01.000 [notice] We now have enough directory information to build circuits.
May 14 19:32:01.000 [notice] Bootstrapped 80%: Connecting to the Tor network

============================================================ T= 1400110321
(Sandbox) Caught a bad syscall attempt (syscall sched_getaffinity)
/usr/bin/tor(+0x32ca30)[0x7f78c1cd2a30]
/lib/x86_64-linux-gnu/libpthread.so.0(pthread_getaffinity_np+0x24)[0x7f78bd61eb34]
/lib/x86_64-linux-gnu/libpthread.so.0(pthread_getaffinity_np+0x24)[0x7f78bd61eb34]
/lib/x86_64-linux-gnu/libpthread.so.0(pthread_getattr_np+0x9e)[0x7f78bd618e3e]
/usr/lib/x86_64-linux-gnu/libasan.so.0(+0x1aa9d)[0x7f78be810a9d]
/usr/lib/x86_64-linux-gnu/libasan.so.0(+0x18872)[0x7f78be80e872]
/usr/lib/x86_64-linux-gnu/libasan.so.0(+0x188bd)[0x7f78be80e8bd]
/usr/lib/x86_64-linux-gnu/libasan.so.0(+0x18a3e)[0x7f78be80ea3e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8062)[0x7f78bd617062]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f78bd146bfd]

Let me know if you need anything else!

comment:12 Changed 7 years ago by nickm

This is with --enable-expensive-hardening and with sandboxing, and it doesn't happen with sandboxing only on this computer?

Is this also with 'User' and 'RunAsDaemon', or any other options that debian likes to set?

comment:13 in reply to:  12 Changed 7 years ago by alphawolf

Replying to nickm:

This is with --enable-expensive-hardening and with sandboxing, and it doesn't happen with sandboxing only on this computer?

Correct. This is the exact same setup as used in testing #11946. The patch for 11946 allows tor to run sandboxed without issue, but recompiling with --enable-expensive-hardening causes a stack trace consistently (three times) at 80% bootstrapped.

Is this also with 'User' and 'RunAsDaemon', or any other options that debian likes to set?

Yes, all of the above, and using the init.d script. I can copy torrc, etc, here if you'd like, but they are the same as in #11946. I can test in other ways if you'd like; I just like to mimic the Debian package since that's what most end users will experience.

comment:14 Changed 7 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.5.x-final

comment:15 Changed 7 years ago by nickm

Resolution: fixed
Status: assignedclosed

fef65fa64341fb70df0e7b34d91d3b08a74e7aad should fix this. Please reopen if it is not working in master.

Note: See TracTickets for help on using tickets.