Sandboxing Instantbird

[sukhbir]

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)?

[ioerror]

Sandboxing on OSX is probably the easiest.

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

​https://github.com/hellais/Buckle-Up

We should also consider the designs of Chrome:

​https://www.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design

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

​https://github.com/s7ephen/OSX-Sandbox--Seatbelt--Profiles

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.

[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:

​https://github.com/subgraph/oz

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

[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: ​https://www.chromium.org/developers/testing/addresssanitizer - 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.

[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: ​https://www.chromium.org/developers/design-documents/sandbox

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

[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).

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

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

[ioerror]

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

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

[ioerror]

I've started to sandbox Ricochet a bit - it seems like I'll have something useful here soon. See ​https://github.com/ricochet-im/ricochet/pull/232 for an example of it.

[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 libminijail.so is 62K and libminijailpreload.so is 64K.

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

ldd minijail0
	linux-vdso.so.1 (0x00007ffc2fdce000)
	libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f549ebbf000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f549e9bb000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f549e611000)
	libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f549e40c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f549edf2000)

[ioerror]

basic amd64 minijail seccomp policy

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

[ioerror]

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.

[ioerror]

We may want to use the latest version of minijail: ​https://chromium.googlesource.com/chromiumos/platform2/+/master/minijail/

[anonym]

I spent a few minutes patching Tails' torbrowser AppArmor profile (which itself is a patched version of the AppArmor profile from Debian Testing's torbrowser-launcher package) to work with Instantbird in the integration branch we have for Tor Messenger. My goal was basically to have it start, be able to connect via XMPP and start and OTR conversation, and zero actual thought went into the patching beyond that (I didn't even look at the full profile). Hence I doubt it will be very useful for you, but FWIW you can see the patch here: ​https://labs.riseup.net/code/issues/8577#note-9

[indolering]

I'm sure you all know about ​Flatpak and ​Bubblewrap already, but I figured I would drop it in here.

[arlolra]

Thanks, yes, we'll be following Yawning's lead on Tor Browser sandboxing with those utilities.

​https://blog.torproject.org/blog/q-and-yawning-angel
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux

[yawning]

I'm not sure how applicable anything I wrote for Tor Browser will end up being.

The distribution model between Tor Birdy and Tor Browser is quite different (extension vs bundle), and none of the code was written to ever support anything other than Tor Browser.

[yawning]

Oh whoops. I misread the ticket and thought this was the thunderbird thing. Well, at least there's bundles, so this is possible.

My point about "the code makes assumptions that it's Tor Browser" still holds in a lot of places. The actual sandboxing code is fairly abstract but none of the install/update/UI stuff is, and doing all of that is tedious and time consuming.

If I were to attempt such a thing (and I probably won't due to lack of time/funding), I'd probably fork the code and produce sandboxed-tor-messeger at first and then try to merge the two.

[arlolra]

If I were to attempt such a thing (and I probably won't due to lack of time/funding), I'd probably fork the code and produce sandboxed-tor-messeger at first and then try to merge the two.

Right, and noone expects you to. I just meant we'd take inspiration from the approach you've taken and try to reuse components where it made sense.

[traumschule]

group tickets related to AppArmorForTBB/tor packages

[traumschule]

<+sukhe> hello. yes, I think it's fine to close the tickets. thanks for doing what we should done earlier :)

sad but true:
​https://blog.torproject.org/sunsetting-tor-messenger

luckily there are alternatives:
​https://blog.torproject.org/tor-heart-onion-messaging

.. and maybe someday

• ​https://cwtch.im (#27364)
• ​https://github.com/warner/magic-wormhole/issues/8