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.
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].
- I have set up a public remote branch [3].
- 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. 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.
- 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.
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.
[1] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=blob;f=Documentat... [2] http://sourceforge.net/projects/libseccomp/ [3] https://github.com/cristiantoader/tor-gsoc-capabilities
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
On Sat, Jun 29, 2013 at 10:55 PM, Jacob Appelbaum jacob@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:
- 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.
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)
-
Cristian-Matei Toader -
Jacob Appelbaum