Shawn Webb
Follow

Looks like the way currently does sandboxing is completely incompatible with .

I'm going to need to really beef up Tor's internal sandboxing framework. I need to write some abstraction layers. Essentially, Tor needs to ask the sandboxing framework for file descriptors (FDs). FDs could be pre-opened (in the case of Capsicum) or could be opened on-the-fly (in the case of seccomp).

This is going to be a major pain (as is usually the case with Capsicum).

Right now, Tor just tells the sandboxing framework "hey, I'm going to need to open this file/resource sometime in the future, so add it to the whitelist."

Later on in the program lifecycle, Tor's code will simply call open[at]() on that resource. Since won't let you create new FDs once cap_enter() is called, this doesn't work. Capsicum works on a per-FD basis, which means 100% of your FDs must be created and set up with the proper rights prior to calling cap_enter().

So, essentially, I have to do at least two things:

1. Enable pre-opening of FDs during sandbox initialization (don't know how to handle sockets, yet).
2. Each and every time Tor tries to open a resource, funnel that attempt through the new sandboxing abstraction layer.

There could be more that I have to do, but this is just after one day of research.

This diff, when submitting to upstream, is going to be YUGE. I'm going to feel sorry for whoever has to do the code review.

I love the enhanced security provides. However, it sure is an epicly major pain to deal with--especially when retrofitting applications for it. Even applications that were developed with other sandboxing frameworks in mind will have issues when integrating Capsicum support.

This also solidifies the need for exploit mitigations that don't require extreme development efforts by application developers. Exploit mitigations like PaX ASLR and PaX NOEXEC pair well with Capsicum and don't need source-level modification of (or direct integration with) applications.

Indeed, combining PaX ASLR, PaX NOEXEC, and Capsicum will provide an execution environment that will really piss off attackers.

@lattera I think the debian grsec packages are pretty easy to use and tightened down. Sadly, those may come to an end after Linus said what he said and grsec starting to look at the proprietary route.

@privatepenguin We at are porting grsecurity over to the BSD world. I haven't used in any official capacity in over a decade. :)

Sign in to participate in the conversation
Mastodon

Follow friends and discover new ones. Publish anything you want: links, pictures, text, video. This server is run by the main developers of the Mastodon project. Everyone is welcome as long as you follow our code of conduct!