Project

General

Profile

Bug #8174

Build Tor with seccomp

Added by Dr_Whax about 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
10/26/2014
Due date:
% Done:

100%

Feature Branch:
feature/8174-tor-with-seccomp
Type of work:
Code
Blueprint:
Starter:
Affected tool:

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?


Related issues

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

Associated revisions

Revision d6b45427 (diff)
Added by Tails developers almost 5 years ago

Document how to build our own Tor package, with seccomp enabled.

Will-fix: #8174.

Revision f7d847c9
Added by Tails developers almost 5 years ago

Merge remote-tracking branch 'origin/feature/8174-tor-with-seccomp' into devel

Fix-committed: #8174

History

#1 Updated by BitingBird about 5 years ago

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 about 5 years ago

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 about 5 years ago

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 about 5 years ago

  • 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 about 5 years ago

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 #8402 to Tor 0.2.5.x (otherwise we'll have to wait until 0.2.6.x), so we could close #7283. We may also be able to close #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 about 5 years ago

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

#7 Updated by BitingBird about 5 years ago

  • Category set to Tor configuration

I suggest to have this discussion during the next meeting.

#8 Updated by intrigeri about 5 years ago

  • 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 about 5 years ago

  • Assignee set to anonym
  • QA Check set to Info Needed

#10 Updated by intrigeri about 5 years ago

  • 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 about 5 years ago

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

#12 Updated by intrigeri almost 5 years ago

  • 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.

#13 Updated by intrigeri almost 5 years ago

  • Assignee changed from anonym to intrigeri

#14 Updated by Tails almost 5 years ago

  • Status changed from Confirmed to In Progress

Applied in changeset commit:ff28e3a220df4d5f7bcfc229368e03099e6ef3e6.

#15 Updated by intrigeri almost 5 years ago

  • % Done changed from 0 to 10
  • Feature Branch set to feature/8174-tor-with-seccomp

#16 Updated by Tails almost 5 years ago

Applied in changeset commit:8d23d0597c07b32bd41b265622a7d03841c99787.

#17 Updated by intrigeri almost 5 years ago

  • Assignee changed from intrigeri to anonym
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

#18 Updated by intrigeri almost 5 years ago

  • Blocks Feature #8889: Automatically test that Tor runs with Seccomp enabled added

#19 Updated by Tails almost 5 years ago

  • Status changed from In Progress to 11
  • % Done changed from 50 to 100

Applied in changeset commit:e18914fdf2a1aa9c31b1794b474ce3bdd80f18be.

#20 Updated by anonym almost 5 years ago

  • Assignee deleted (anonym)
  • QA Check changed from Ready for QA to Pass

#21 Updated by BitingBird almost 5 years ago

  • Status changed from 11 to Resolved

Also available in: Atom PDF