Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #5756

Closed (moved)
Open
Opened May 03, 2012 by Trac@tracbot

Seccomp system call whitelisting on Linux

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.

Trac:
Username: bugmenot

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: 0.2.5.x-final
Milestone
Tor: 0.2.5.x-final
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#5756