Opened 4 years ago
Last modified 15 months ago
#10943 new task
Sandboxing Instantbird
Reported by: | sukhbir | Owned by: | |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Applications/Tor Messenger | Version: | |
Severity: | Normal | Keywords: | |
Cc: | gk, arlolra, erinn, yawning | Actual Points: | |
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description (last modified by )
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
Attachments (1)
Change History (30)
comment:1 Changed 4 years ago by
Cc: | gk added |
---|
comment:2 Changed 3 years ago by
Keywords: | TorMessengerPublic added |
---|---|
Parent ID: | → #14161 |
comment:3 Changed 3 years ago by
Cc: | arlolra added |
---|
comment:4 Changed 3 years ago by
Parent ID: | #14161 |
---|
comment:5 Changed 3 years ago by
comment:6 Changed 3 years ago by
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 3 years ago by
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.
comment:8 Changed 3 years ago by
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?
comment:9 Changed 3 years ago by
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 3 years ago by
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 3 years ago by
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 3 years ago by
I should mention that my xpra example does leave a log on the disk - so we should disable that logging, obviously.
comment:13 Changed 3 years ago by
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.
comment:14 Changed 3 years ago by
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.
comment:15 Changed 3 years ago by
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)
Changed 3 years ago by
Attachment: | tor-messenger-seccomp-amd64.policy.sorted added |
---|
basic amd64 minijail seccomp policy
comment:16 Changed 3 years ago by
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 3 years ago by
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.
comment:18 Changed 3 years ago by
We may want to use the latest version of minijail: https://chromium.googlesource.com/chromiumos/platform2/+/master/minijail/
comment:19 Changed 2 years ago by
Cc: | erinn added |
---|---|
Severity: | → Normal |
comment:20 Changed 2 years ago by
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
comment:21 Changed 2 years ago by
Keywords: | SponsorO removed |
---|
comment:22 Changed 2 years ago by
Keywords: | TorMessengerPublic removed |
---|
comment:23 Changed 18 months ago by
Owner: | ioerror deleted |
---|---|
Status: | new → assigned |
comment:24 Changed 18 months ago by
Status: | assigned → new |
---|
comment:25 Changed 15 months ago by
I'm sure you all know about Flatpak and Bubblewrap already, but I figured I would drop it in here.
comment:26 Changed 15 months ago by
Cc: | yawning added |
---|
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
comment:27 Changed 15 months ago by
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.
comment:28 Changed 15 months ago by
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.
comment:29 Changed 15 months ago by
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.
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.