Opened 6 years ago

Last modified 22 months ago

#10943 closed task

Sandboxing Instantbird — at Version 17

Reported by: sukhbir Owned by: ioerror
Priority: Medium Milestone:
Component: Archived/Tor Messenger Version:
Severity: Normal Keywords: apparmor
Cc: gk, arlolra, erinn, yawning Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by ioerror)

We should sandbox Instantbird on all platforms. We particularly need someone to do this on Windows since ioerror will take care of it for OS X and Linux.

What are the chances of us getting a make install target or after unpacking the binary release having a shell script to install it into a standard location (as root, which enables loading apparmor, etc)?

Child Tickets

Change History (18)

comment:1 Changed 6 years ago by gk

Cc: gk added

comment:2 Changed 6 years ago by sukhbir

Keywords: TorMessengerPublic added
Parent ID: #14161

comment:3 Changed 5 years ago by arlolra

Cc: arlolra added

comment:4 Changed 5 years ago by arlolra

Parent ID: #14161

comment:5 Changed 5 years ago by ioerror

Sandboxing on OSX is probably the easiest.

I think that we should consider using Arturo's BuckleUp for OS X sandboxing:

We should also consider the designs of Chrome:

We may also want to look at the profiles of other programs:

I think while this isn't exactly sandboxing, we should also put our app in the OS X App store. Distribution and updating is a security issue of the highest order - lets make sure the app is not only sandboxed but also signed, available without the appstore and in the appstore as well.

comment:6 Changed 5 years ago by ioerror

Sandboxing on GNU/Linux is dependent on how we ship - if we're packaging for Debian GNU/Linux (rather than HURD), we should probably include an AppArmor profile as well as seccomp support. If we're packaging for another platform, I think we need to consider what is possible - SELinux policy files seem to be relevant, as well as others.

However - with that said - I'd like to suggest that we use Subgraph's sandboxing system:

We will absolutely not build something better for this application in the next month or two.

comment:7 Changed 5 years ago by ioerror

We should ensure that we review the build process to make it both deterministic and to ensure that we enable all of the relevant hardening options.

Furthermore, I'd like to point out that while not exactly sandboxing, we should build any relevant Instantbird component with ASan: - this means that on OSX and GNU/Linux, we should be doing 64bit builds. My suggestion would be to produce only 64bit builds that meet our security expectations.

comment:8 Changed 5 years ago by ioerror

I'm not super clear on what we should do to sandbox Windows of any version. I think that we should look at Chrome and consider it as the gold standard:

I'd love to hear from a Windows expert - anyone?

comment:9 Changed 5 years ago by ioerror

If OZ isn't available for GNU/Linux (eg: not SubgraphOS) - we should probably just stick to packaging and using two basic techniques for sandboxing (eg: AppArmor and seccomp) at first.

Ideally, if we do it properly - Tor can be sandboxed with seccomp by default (it is already in Tor) and then InstantBird components can be sandboxed with seccomp (which we need to add). Then all of this should be sandboxed in AppArmor or SELinux policies. With proper isolation, I can see a way to totally ensure Tor has very limited abilities (eg: TCP is allowed, a single set of directories for read/write, nothing else), while InstantBird could even be forbidden from using TCP/IP (by using Socks5 over Tor's UnixSocket).

comment:10 Changed 5 years ago by ioerror

On GNU/Linux - I'd like to suggest that we should plan to isolate from the nightmare that is XWindows as much as is possible. One way is to do something like this:

xpra start :1 --start-child=xeyes && xpra attach :1

This is easily accomplished by doing:

xpra start :1 --start-child=start-tor-messenger && xpra attach :1

I suspect the smart thing would be to patch start-tor-messenger to be xpra aware.

I would suggest the following as a starting point for xpra as a basic XWindows condom:

xpra start :23 --start-child=./start-tor-messenger --exit-with-children --no-clipboard --no-pulseaudio --no-microphone --no-sharing --no-xsettings --no-notifications --opengl=no --no-mdns --no-cursors --no-bell && xpra attach :23 --no-clipboard --no-tray --title=@title@

I ran this on an x86_64 Debian system with xpra v0.14.10. Tor Messenger worked as expected but now it cannot be easily used to be an XWindows key/event logger. It is isolated even from the clipboard - which may be a bit too much.

As a general reminder: we must *also* sandbox the application to prevent it from connecting to the default XServer - this needs to be done either in AppArmor or in another sandboxing framework.

comment:11 Changed 5 years ago by ioerror

If anyone wants to suggest Wayland, I'd like to suggest a working example that will work today. If not, I'd like to suggest xpra as our XWindows isolation of choice for now.

comment:12 Changed 5 years ago by ioerror

I should mention that my xpra example does leave a log on the disk - so we should disable that logging, obviously.

comment:13 Changed 5 years ago 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:

Grab the code for minijail here:

git clone

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.

comment:14 Changed 5 years ago by ioerror

I've started to sandbox Ricochet a bit - it seems like I'll have something useful here soon. See for an example of it.

comment:15 Changed 5 years ago by ioerror

After spending part of the weekend looking into minijail stuff - I've decided that it makes sense to do three things at least:

  • enable all build hardening options (AddressSanitizer, gcc/clang/linker hardening, etc)
  • write some kind of sandbox policy when the OS provides a facility (eg: GNU/Linux: AppArmor, OSX: seatbelt, Windows: o_0)
  • write or use a small launcher for other priv dropping (GNU/Linux: minijail/mbox/custom, OSX: o_0, Windows: o_0)

Does it seem possible to ship a copy of minijail or related libraries? minijail0 is 61K is 62K and is 64K.

minijail0 or a similar tool may need libcap-dev or perhaps not if we don't need capabilities:

ldd minijail0 (0x00007ffc2fdce000) => /lib/x86_64-linux-gnu/ (0x00007f549ebbf000) => /lib/x86_64-linux-gnu/ (0x00007f549e9bb000) => /lib/x86_64-linux-gnu/ (0x00007f549e611000) => /lib/x86_64-linux-gnu/ (0x00007f549e40c000)
	/lib64/ (0x00007f549edf2000)
Last edited 5 years ago by ioerror (previous) (diff)

Changed 5 years ago by ioerror

basic amd64 minijail seccomp policy

comment:16 Changed 5 years ago by ioerror

I've attached a seccomp policy to be used with minijail like so:

minijail0 -n -S  tor-messenger-seccomp-amd64.policy.sorted ./start-tor-messenger

It would also be possible to simply detect the presence of minijail in the start-tor-messenger script and then exec instantbird with it as the caller. This would also allow us to make a tighter policy as the current policy includes all of the syscalls required to run the full shell script - which may or may not be what we want or need.

comment:17 Changed 5 years ago by ioerror

Description: modified (diff)

I believe that we need an install target for tor-messenger - once we do - I can begin to sandbox it with AppArmor. I think that we must drop the "portable" idea as the only way to run things.

Note: See TracTickets for help on using tickets.