Opened 4 years ago

Last modified 14 months ago

#17521 assigned enhancement

Support capsicum(4) on FreeBSD

Reported by: yawning Owned by: shawn.webb
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay, security, sandboxing, BSD, capsicum, 034-triage-20180328, 034-removed-20180328
Cc: shawn.webb@…, ln5 Actual Points:
Parent ID: Points:
Reviewer: ahf Sponsor:


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) (​ 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.

Child Tickets

Change History (26)

comment:1 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:2 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

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

comment:3 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:4 Changed 2 years ago by dgoulet

Keywords: tor-core removed

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

comment:5 Changed 2 years ago by nickm

Keywords: capsicum added

comment:6 Changed 21 months ago by shawn.webb

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

comment:7 Changed 21 months ago by shawn.webb

Cc: shawn.webb@… added
Owner: set to shawn.webb
Status: newassigned

comment:8 Changed 20 months ago by ln5

Cc: ln5 added

comment:9 Changed 20 months ago by shawn.webb

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.

comment:10 Changed 20 months ago by teor

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.

comment:11 Changed 20 months ago by shawn.webb

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:

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.

comment:12 Changed 20 months ago by shawn.webb

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

comment:13 Changed 20 months ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.3.x-final

comment:14 Changed 19 months ago by shawn.webb

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.

comment:15 Changed 19 months ago by ahf

Reviewer: ahf

comment:16 Changed 16 months ago by dgoulet

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

comment:17 Changed 15 months ago by shawn.webb

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?

comment:18 Changed 15 months ago by ahf

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.

comment:19 Changed 15 months ago by shawn.webb

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.

comment:20 Changed 15 months ago by 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 fails, but curl works ( is the IP of

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.

comment:21 Changed 15 months ago by shawn.webb

Bug report submitted to libevent:

comment:22 Changed 15 months ago by teor

Version: Tor: unspecified

comment:23 Changed 15 months ago by shawn.webb

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.

comment:24 Changed 14 months ago by nickm

Keywords: 034-triage-20180328 added

comment:25 Changed 14 months ago by nickm

Keywords: 034-removed-20180328 added

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

comment:26 Changed 14 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

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

Note: See TracTickets for help on using tickets.