[tor-bugs] #10943 [Tor Messenger]: Sandboxing Instantbird
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Jul 21 23:16:02 UTC 2015
#10943: Sandboxing Instantbird
-------------------------------+------------------------------------------
Reporter: sukhbir | Owner: ioerror
Type: task | Status: new
Priority: normal | Milestone:
Component: Tor Messenger | Version:
Resolution: | Keywords: SponsorO, TorMessengerPublic
Actual Points: | Parent ID:
Points: |
-------------------------------+------------------------------------------
Comment (by ioerror):
It may make sense to ship a non-root version (but it still needs a CAP or
two) of minijail to launch xpra and then re-launch a minijail sandboxed
xpra that starts a minijailed start-tor-messenger:
https://chromium.googlesource.com/chromiumos/platform/minijail/
https://www.chromium.org/chromium-os/chromiumos-design-docs/system-
hardening
Grab the code for minijail here:
{{{git clone
https://chromium.googlesource.com/chromiumos/platform/minijail}}}
If we're installing it systemwide, I think weaving in minijail is not such
a crazy idea. If we're not, I think we may be better off using seccomp and
AppArmor properly.
These are all ghetto sandboxing ideas that isolate our Tor Messenger App
from the system - they do not actually help to secure the internal state
of say, TM from itself. Tor is already seccomp'ed and set to disable easy
debugger attachment. We should ensure the same for TM itself and if
possible, we should isolate different parts of the app internally.
Ideally, the OTR code should be run in a totally different process, so we
can compartmentalize it into an oracle without direct memory access. This
would at least ensure that code exec or a memory leak/arbitrary read in
the XUL app won't turn into a leaked OTR identity key.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10943#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list