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

[Jacob Appelbaum <jacob@xxxxxxxxxxxxx>]

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!

> 
> 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?

> - 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. ;-)

> - 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.

> - 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?

Thanks for working on improving Tor - I think you're off to a great start!

All the best,
Jacob
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev