Bug #8174: Build Tor with seccomp

Bug #8174

Build Tor with seccomp

Added by Dr_Whax 2014-10-26 01:26:13 . Updated 2015-02-24 22:48:07 .

Status:

Resolved

Priority:

Normal

Assignee:

Category:

Target version:

Tails_1.3

Start date:

2014-10-26

Due date:

% Done:

100%

Feature Branch:

feature/8174-tor-with-seccomp

Type of work:

Code

Blueprint:

Starter:

Affected tool:

Deliverable for:

Description

ioerror reports in #tor-dev: “Oct 25 22:47:06.000 [warn] This version of Tor was built without support for sandboxing. To build with support for sandboxing on Linux, you must have libseccomp and its necessary header files (e.g. seccomp.h).”

Since we ship a kernel which version is >= 3.5, the kernel has seccomp support. However, we should ship the following package to make it work: libseccomp2

Thoughts?

Subtasks

Related issues

Related to Tails - ~~Feature #8352~~: Add a Wheezy + backports chroot on debomatic.lizard	Rejected	2014-12-01
Blocks Tails - ~~Feature #8889~~: Automatically test that Tor runs with Seccomp enabled	Resolved	2015-02-11

History

#1 Updated by BitingBird 2014-10-26 06:07:32

You don’t really explain what seccomp is about, and I can’t check their website because they want me to accept cookies…

#2 Updated by intrigeri 2014-10-26 07:09:13

> ioerror reports in #tor-dev: “Oct 25 22:47:06.000 [warn] This version of Tor was
> built without support for sandboxing. To build with support for sandboxing on Linux,
> you must have libseccomp and its necessary header files (e.g. seccomp.h).”

Good catch.

> Since we ship a kernel which version is >= 3.5, the kernel has seccomp support.
> However, we should ship the following package to make it work: libseccomp2

Well, not exactly.

Even if we shipped libseccomp2, we would not magically get a Tor that was build with seccomp support. And since seccomp is not in Wheezy, deb.torproject.org’s Tor package for Wheezy is not built with seccomp support (as the quoted log message above says). So, our options seem to be:

convince weasel to build Tor for Wheezy with seccomp support, using libseccomp-dev from wheezy-backports: unlikely to happen, as 1. the resulting binary package would be uninstallable on Wheezy (unless the dependency on libseccomp2, in the binary package, was demoted to e.g. a mere Suggests, but that would be ugly); 2. this would force him to taint his Wheezy build chroot with backports, which feels wrong
rebuild Tor ourselves for Wheezy + backports

#3 Updated by throwaway27 2014-10-27 00:14:53

BitingBird wrote:
> You don’t really explain what seccomp is about, and I can’t check their website because they want me to accept cookies…

Seccomp is a kernel-level syscall whitelist that minimizes the exploitation surface area of the kernel. If a confined process tries to send a syscall to the kernel that is not on the whitelist, it is sent SIGKILL.

https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt

(If you don’t want cookies, why not have your client simply ignore cookies?)

About Tails maintaining its own Tor, I personally like that idea. It could be done with more hardening flags too, not just seccomp support.

#4 Updated by intrigeri 2014-11-07 14:45:47

Subject changed from Ship seccomp to Build Tor with seccomp
Status changed from New to Confirmed
Assignee changed from Dr_Whax to anonym
QA Check set to Info Needed
Type of work changed from Code to Discuss

So, next step seems to be to discuss whether we want to bother rebuilding Tor ourselves. anonym, what do you think?

#5 Updated by anonym 2014-12-01 09:19:57

intrigeri wrote:
> So, next step seems to be to discuss whether we want to bother rebuilding Tor ourselves. anonym, what do you think?

I’d find this acceptable; building and uploading a Tor .deb is trivial work, and the maintenance overhead should be pretty minimal.

Bonus: this would open up for including other Tor patches too, and I’m thinking specifically of the TBB ones. For instance, we could get rid of our Tor Launcher customizations by including the patch that backports the fix for Tor bug Feature #8402 to Tor 0.2.5.x (otherwise we’ll have to wait until 0.2.6.x), so we could close ~~Bug #7283~~. We may also be able to close ~~Feature #7087~~ by removing our bundled Tor Launcher and instead unpacking TBB’s Tor Launcher xpi and making it into a standalone XUL application.

#6 Updated by anonym 2014-12-01 09:20:24

Assignee deleted (~~anonym~~)
QA Check deleted (~~Info Needed~~)

#7 Updated by BitingBird 2014-12-01 10:48:07

Category set to Tor configuration

I suggest to have this discussion during the next meeting.

#8 Updated by intrigeri 2014-12-01 17:37:26

Category deleted (~~Tor configuration~~)
Target version set to Tails_1.3
Type of work changed from Discuss to Code

anonym wrote:
> I’d find this acceptable; building and uploading a Tor .deb is trivial work, and the maintenance overhead should be pretty minimal.

OK, I’m now convinced. And likely you’re the one who will be doing most of this work as the RM, so your call => turning this into a code ticket, tentatively flagging for 1.3.

So, now we need a wheezy + backports chroot on debomatic.lizard and that’s all, right?

#9 Updated by intrigeri 2014-12-01 17:37:46

Assignee set to anonym
QA Check set to Info Needed

#10 Updated by intrigeri 2014-12-01 17:46:50

Assignee deleted (~~anonym~~)
QA Check deleted (~~Info Needed~~)

intrigeri wrote:
> So, now we need a wheezy + backports chroot on debomatic.lizard and that’s all, right?

Discussed this privately with anonym: neither he nor I need it, but other candidate emergency RMs might need it, so we need it, but it’s low priority and not blocking this ticket.

#11 Updated by intrigeri 2014-12-01 17:47:47

related to ~~Feature #8352~~: Add a Wheezy + backports chroot on debomatic.lizard added

#12 Updated by intrigeri 2015-02-10 14:28:24

Assignee set to anonym

Apparently we forgot to assign this ticket to the RM. anonym, if you can’t do it, please tell me in the next few hours, I might be able to take care of it.