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:
- 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 brokenin phase 1 by adding capabilities, they can be re-enabled at the cost of security.
3. Figure out what functionality should be split into separateprocesses, 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