Opened 7 years ago

Closed 5 years ago

#5756 closed enhancement (implemented)

Seccomp system call whitelisting on Linux

Reported by: bugmenot Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: seccomp security sandbox tor-relay
Cc: Actual Points:
Parent ID: #5791 Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

TicketTypeStatusOwnerSummary
#9168enhancementclosednickmGSOC seccomp stage 1
#9249enhancementclosednickmGSOC seccomp stage 2

Change History (14)

comment:1 Changed 7 years ago by arma

Component: Development ProgressTor bundles/installation
Status: newassigned

comment:2 Changed 7 years ago by arma

We're going to need some help generating the policies. I would hope there's an easy to use tool to generate most of it for you, but, well, ha.

comment:3 Changed 7 years ago by Sebastian

I don't buy that this is a tor bundles/installation bug. It reads like we'd need support in the applications themselves, not something we could add in through a launcher script

comment:4 in reply to:  3 Changed 7 years ago by arma

Status: assignednew

Replying to Sebastian:

I don't buy that this is a tor bundles/installation bug. It reads like we'd need support in the applications themselves, not something we could add in through a launcher script

I agree. Where to put it?

comment:5 Changed 7 years ago by Sebastian

Add one child ticket per TBB component maybe. Hrm.

comment:6 Changed 7 years ago by nickm

It seems like this would support one of the things we'd hoped we could do with Linux capabilities, but which they don't actually help with. (That thing being disabling pieces functionality available to ordinary users. Ordinary Linux caps only seemed to allow disabling root-level abilities.)

comment:7 Changed 7 years ago by arma

Parent ID: #5791

comment:8 Changed 7 years ago by nickm

Component: Tor bundles/installationTor Relay

comment:9 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-final

I think we could do a decent job here without refactoring the rest of Tor too much.

The tricky part would be that, when seccomp was in use, we'd want to restrict the places we can open() and restrict the stuff we can exec(). But we could say for now that enabling seccomp means that Tor restricts these things immediately after it reads its configuration file, and you can't (for example) add new pluggable transports once seccomp is enabled.

(Refactoring Tor could let us compartmentalize stuff even better, and could be helpful/needful for better security on other platforms, but it's possibly a good idea to do what we can now.)

comment:10 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:11 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:12 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

I really want this, but it's not going to get done in 4 days.

comment:13 Changed 6 years ago by nickm

This is happening now in 0.2.5.

comment:14 Changed 5 years ago by nickm

Resolution: implemented
Status: newclosed

The main part of this is implemented; the rest is properly classified as "enhancements to seccomp syscall whitelisting", so I'm closing this one.

Note: See TracTickets for help on using tickets.