Support capsicum(4) on FreeBSD

Filing this so it's on our radar as a potential project. It's a nice to have, but more suited towards a GSoC/TSoP project than anything else IMO.

FreeBSD has a sandboxing/capabilities framework called capsicum(4) (​https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4). It would be good for tor to support this in addition to seccomp2, just so people aren't out of luck on non-Linux systems wrt sandboxing.

changed milestone to %Tor: unspecified

added 034-removed-20180328 034-triage-20180328 BSD capsicum component::core tor/tor milestone::Tor: unspecified owner::shawn.webb priority::medium reviewer::ahf sandboxing security severity::normal status::assigned tor-relay type::enhancement labels

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

The tor-core keyword doesn't really make sense now that we have "Core Tor/Tor" for component.

Trac:
Keywords: tor-core deleted, N/A added

Trac:
Reviewer: N/A to N/A
Keywords: N/A deleted, capsicum added

I've started work on this on behalf of HardenedBSD.

Trac:
Username: shawn.webb

Trac:
Username: shawn.webb
Status: new to assigned
Owner: N/A to shawn.webb
Cc: N/A to shawn.webb@hardenedbsd.org

Trac:
Cc: shawn.webb@hardenedbsd.org to shawn.webb@hardenedbsd.org, ln5

I've made a ton of progress on this. I now have a mostly capsicumized Tor. The very basics are working as of this writing.

As it stands, what's left to do:

1. Write sandbox wrappers for a few more libc calls (gmtime(3), socketpair(2), etc).
2. Implement proper memory management (like, call free(3) where appropriate).
3. Clean up a whole freakton of debug code.
4. Write the Linux equivalent wrapper code (likely macros that just point to the corresponding libc functions).
5. Build full body-suit armor as the person who's tasked with reviewing the ensuing patch will likely want to stab me.

I will have a solution to demo in place by the time the Montreal meetup happens.

Trac:
Username: shawn.webb

Tor has an existing abstraction layer for accessing seccomp'd syscalls on Linux, using a bunch of functions prefixed with sandbox_. Is it possible to extend or modify that abstraction layer, rather than adding a separate interface for FreeBSD? That would make it easier to maintain once it's merged.

The problem is that seccomp2 uses a filtering approach. Essentially, once you've whitelisted the things you want to access, you can call open(2), socket(2), etc. at will and on demand.

Capsicum takes a completely different approach, one that's fully incompatible with seccomp2. I've writting a PoC do demonstrate the approach I'm taking with this ticket: https://github.com/lattera/PoCs/tree/master/capsicum_fdpassing

Note that the code I've written in the Tor codebase has diverged quite a bit from the PoC. The PoC is ugly code meant to serve as a brain dump and code testing area.

Trac:
Username: shawn.webb

I've now made the code public. There's still a bit of work left to do.

https://github.com/lattera/tor/tree/hardening/capsicum

Trac:
Username: shawn.webb

Trac:
Milestone: Tor: unspecified to Tor: 0.3.3.x-final

This work is nearing completion for a milestone 1. I've diverged quite a bit from the original PoC. How should I proceed from here in getting the code reviewed and merged upstream?

The only known issue is that when sandbox mode is enabled on FreeBSD/HardenedBSD, transparent proxy mode breaks. I'm researching the breakage. Given that transparent proxy mode is not the primary use case nor is widely used, I feel like the current work can go in (pending code review and adjustments resulting from the review) with an errata patch later on.

Trac:
Username: shawn.webb

Trac:
Reviewer: N/A to ahf

Trac:
Milestone: Tor: 0.3.3.x-final to Tor: 0.3.4.x-final

I'm going to bring this work up-to-date with the latest master branch. It has a few merge conflicts. @ahf, would you have time to review this work after the merge conflicts are resolved?

Trac:
Username: shawn.webb

Yep! I'm going to Rome next week for the Tor dev meeting, so I probably wont get around to it until after the meeting is over.

Cool. I'll also try to spend some time on the transparent proxy mode. I think I know what's going on there. The /dev/pf file descriptor probably needs ioctl capabilities.

Trac:
Username: shawn.webb

So it turns out that the transproxy issue is with libevent, which creates and maintains its own sockets. I've tested transproxy and it's working, however DNS resolutions fail.

So curl http://4.ifconfig.pro/ fails, but curl http://108.61.202.109/ works (108.61.202.109 is the IP of 4.ifconfig.pro).

Given that this is an issue with libevent and not tor, I believe that Capsicum in tor itself is working as intended. I'll open a bug report with libevent to see if we can figure out how to teach it to be Capsicum-safe. Chances are, it may need a sockets abstraction API. Essentially, you'll register a callback for whenever a socket needs to be created. libevent would call that callback instead of socket(2) directly.

Trac:
Username: shawn.webb

Bug report submitted to libevent: https://github.com/libevent/libevent/issues/601

Trac:
Username: shawn.webb

Trac:
Version: Tor: unspecified to N/A

It looks like libevent not being Capsicum-friendly also affects Capsicum support when Tor is used as a relay. We need to fix libevent first before the ORPort and DNSPort options work when Capsicum is enabled via the Sandbox option.

Effectively, that means that this new Capsicum support is only applicable to running client nodes.

Trac:
Username: shawn.webb

Trac:
Keywords: N/A deleted, 034-triage-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

Trac:
Keywords: N/A deleted, 034-removed-20180328 added

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Trac:
Milestone: Tor: 0.3.4.x-final to Tor: unspecified

moved to tpo/core/tor#17521 (closed)