[tor-dev] [GSOC] Status report - Tor capabilities

[Cristian-Matei Toader]

On Sat, Jun 29, 2013 at 10:55 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> Hello,
>
> Cristian-Matei Toader:
>> Hello tor-dev,
>>
>> As a small reminder the purpose of the project is to create
>> capabilities based sandboxing for Tor, which may only allow the
>> program to execute a number of predefined syscalls.
>
> Is it really capabilities based? It seems that it best described as a
> syscall filter - where seccomp tells the kernel to disable certain
> system calls, rather than by actually limiting specific capabilities
> over all, no? I suppose in a sense, it is a capability sandbox - though
> there are other systems that more tightly fit that description, I think.
> Not to be too nit-picky, it is important!

The project is meant to restrict access control through syscall
filtering. Right now there is only one rather permissive filter which
applies to the whole application, but as an end result the code will
be refactored into multiple processes each having an appropriate
syscall filter, or in other words will be running in their own
sandboxes.

I am not sure why it wouldn't be a capabilities sandbox; is it because
it is not based on an actual access token? because if so, in theory
the token does exist but it's simply not managed by the application,
but rather by the OS.

The Capsicum [1] framework for instance is based on a similar idea
with the same outcome and is advertised to be enable developers to
create a capabilities sandbox.

The wikipedia article on sandboxes [2] classifies seccomp filters as
different from capabilities sandboxes mainly because of its
granularity which has an all or nothing approach, but this is no
longer true for seccomp2 so the article probably needs to be updated.

>>
>> For the past 2 weeks:
>>
>> - I have consulted with Nick Mathewson (nickm) and agreed upon using
>> seccomp2 [1], and more recently a library built on top of that called
>> libseccomp [2].
>>
>
> This is a good choice - though there are systems where libseccomp2 is
> unavailable or other systems are also available, what are your thoughts
> about such systems?

Maybe the title of the project should be changed in the future, but
the current linux solution will be seccomp2 which has kenel support
starting with version 3.5; for older kernel versions it would probably
disabled, or at least I am not aware of any alternative solutions, as
seccomp(1) doesn't quite fit the task.

Ok so why did I say the name should probably be changed. It's because
what Tor needs si a sandboxing mechanism, and the project will try to
split it up in sections which require different access levels. The
process sandboxing mechanism is OS / architecture dependent; I haven't
focused that much on finding the best solution for each platform, but
from what I have looked into so far:
- linux ~ seccomp2
- FreeBSD ~ Capsicum
- Windows ~ from what I understand sandboxing can be done using API
hooks and redirects, but I have no experience doing that.
- MacOSX  ~ Seatbelt (similar to seccomp, I'll try find a better
alternative when the time comes)

So far I have focused on developing a solution for the linux platform
using seccomp2, and have only briefly investigated solutions for the
other platforms.

>> - I have set up a public remote branch [3].
>>
>
> I've read your work as of today - it looks like an interesting start.
>
> On ChromeOS, we jail tlsdate with libseccomp2 filters using minijail. It
> makes it exceptionally easy to update policies and to audit those
> policies. It also in theory allows for many different methods of
> execution with different policies - though we have only one policy at
> the moment per CPU architecture.
>
> Here is one of the policy files:
>
>
> https://github.com/ioerror/tlsdate/blob/master/tlsdate-seccomp-amd64.policy
>
> It may be useful or ease maintenance to add minijail like policy files
> to Tor's repo. This could automatically generate source code that
> includes whatever is in those policy files. This will allow for
> experimentation with various policies using minijail, as well as helping
> keep things in sync across architectures or other sandboxing systems.
> Auto-generating policy files into code is likely to help with subtle
> maintenance changes. It will also help us on platforms where sandboxing
> does not happen inside of an application in the way that libseccomp2
> expects it.
>
> Also, I guess it is easy to use this to fuzz tor and related programs:
> we just minijail it and then see if everything handles total arbitrary
> syscall failure gracefully. ;-)

Thank you for that! I'll have a look over how you manage those policy
files using minijail. Basically, right now as a first step there is
only one filter inside the code. Using policy files like that sounds
like a very good and clean idea which I'll incorporate as soon as
possible.

>> - We have agreed on a 3 step plan for the project:
>>     1. General sandbox based on a single (permisive) filter which
>> restricts tor to using a number of syscalls.
>
> Sounds good. It might make sense to explicitly deny every syscall as
> well as adding the ones we know we require for full operation. This may
> ease friction with other developers who may add a system call here or there.
>
>>     2. Add configuration option for step 1, if any parts were broken
>> in phase 1 by adding capabilities, they can be re-enabled at the cost
>> of security.
>
>
>>     3. Figure out what functionality should be split into separate
>> processes, based on our experience from step 1 and step 2.
>>
>
> Do you have any thoughts on tor-fw-helper and similar tools, say like,
> tor-resolve? Those seem like prime candidates for extreme lockdown.

I haven't thought about that. Right now they will inherit the filter
of the process that launched them. I will try to make the sandbox as
restrictive as possible without breaking anything overall, not just
for those tools. I'll have to look into what restrictions should apply
to different execve processes, thank you for pointing this out.

>> - So far I have implemented step 1 using both libseccomp and seccomp2
>> [3]. Step 1 was developed in such a way that nothing from tor should
>> be broken at the moment; What this means is that sandboxing currently
>> exists in the remote branch, but is fairly coarse and will need some
>> fine tuning at a later stage such as only allowing specific files to
>> be open, or allowing the exec syscall to be called with specific
>> parameters.
>>
>
> It looks reasonably sane. I think Nick already gave you most of the
> feedback that I would otherwise volunteer.
>
> As a bit of general feedback, I think your code looks reasonably clean -
> though it is written with a single sandbox in mind. It is also written
> with a sorta-difficult to maintain policy-in-code-only process. Later, I
> bet it would make sense to auto-generate policies as I've already said a
> few times. :)
>
>> These days I will be adding command line support, which is basically
>> step 2, which will be followed by a code review and merge in the
>> master branch.
>>
>
> What do you envision for command line support? Just flipping Sandbox to
> true?

I have pushed a few changes the other day including command line
support. So far yes, you have to set it to true (defaults to false)
and takes availability for the platform into account. If a time will
come when there will be more than one solution per OS, then it would
make sense to change this.

> Thanks for working on improving Tor - I think you're off to a great start!
>
> All the best,
> Jacob

Sorry for the late response and thank you again for all the questions,
they have definitely helped a lot!

Looking forward to more feedback in the future.

References:
[1] Watson, Robert NM, et al. "Capsicum: Practical Capabilities for
UNIX."USENIX Security Symposium. 2010.
[2] http://en.wikipedia.org/wiki/Sandbox_(computer_security)