[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #5756 [Development Progress]: Seccomp system call whitelisting on Linux
#5756: Seccomp system call whitelisting on Linux
--------------------------------------+-------------------------------------
Reporter: bugmenot | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Development Progress | Version:
Keywords: seccomp security sandbox | Parent:
Points: | Actualpoints:
--------------------------------------+-------------------------------------
This is a feature request/suggestion that applies to the Linux-compatible
software developed as part of the Tor project such as Tor and obfsproxy.
Recently Will "redpig" Drewry released his seccomp patch that allows
processes to describe a policy for which system calls the binary should be
allowed to call during execution.
After the policy is finalized, the kernel will match syscalls against the
policy, limiting what an attacker can do in the event of a compromise.
Be aware that this new patch is different from the original "seccomp"
patch submitted by the Chrome project.
The old patch had a static whitelist of syscalls, this new one allows
dynamic policy construction upon execution and also allows the programmer
to define policies for the parameters passed to the syscalls.
Here are some related links:
http://outflux.net/teach-seccomp/
https://github.com/redpig/linux
http://sourceforge.net/projects/libseccomp/
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-
precise.git;a=blob;f=Documentation/prctl/seccomp_filter.txt;hb=HEAD
http://scarybeastsecurity.blogspot.fr/2012/04/vsftpd-300-and-seccomp-
filter.html
Ubuntu 12.04 (the most recent LTS release) comes integrated with this
patch and it seems like there are good chances the patch will go upstream.
We should consider the possibility of using it for current and future
projects that could benefit from sandboxing.
Chrome decided to use the original seccomp prctl option in their rendering
processes which their "privileged" code then talks to using an inherited
file descriptor.
If we cannot define a sufficiently strict policy for the entire process,
we should consider putting as much functionality as possible into a
confined process to limit our attack surface.
I am not sure if this belongs here as a feature request or on a mailing-
list, but I would like to see some discussion about the feasibility of
using this sandboxing feature for the Linux builds.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5756>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs