[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