14:59:00 <sysrqb> #startmeeting sandboxing tor browser
14:59:00 <MeetBot> Meeting started Tue Jul 24 14:59:00 2018 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:00 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:25 <sysrqb> hi!
14:59:46 * tjr waves
14:59:57 <GeKo> o/
15:01:27 <sysrqb> oh, tjr, is the mojave doc public or should that not be archived?
15:02:06 <tjr> It's public
15:02:39 <sysrqb> okay, i wasn't sure, so i didn't include it in the emails
15:02:42 <sysrqb> https://docs.google.com/document/d/13l_XosCmGpf882q-Q63h5ZYuyLr4_r3sWZ0Lf5ZSFCQ/edit#
15:03:04 <sysrqb> Google Doc outlining new security/sandboxing features of OS X 10.14
15:03:14 <sysrqb> we can take those into consideration, too
15:04:24 <sysrqb> maybe one m ore minute and then we can start
15:04:40 <sysrqb> small group today
15:05:57 <sysrqb> okay. so, we're discussing our objectives with sandboxing tor browser, and discussing what that means on each of the supported platforms
15:06:45 <sysrqb> we may try replicating the sand sandboxed environment on each OS, or we can create different environemnts based on the best sandboxing mechanisms available on each platform
15:07:38 <sysrqb> containerize on all the platforms vs create OS-specific sandboxes
15:07:44 <sysrqb> as a quick overview
15:08:24 <sysrqb> on Linux, we have - what are now considered - containers: per-process namespace isolation of networking, mounts, IPC, etc
15:08:59 <sysrqb> on OS X, we have various filesystem and syscall filtering and restrictions
15:09:57 <sysrqb> on Windows, we have privilege reduction and file system/network filtering
15:10:09 <sysrqb> (these are not very good desriptions)
15:10:12 <tjr> This si the current state of sandboxing or the options we have for each platform?
15:10:40 <sysrqb> There are more options available on Windows, as well
15:11:13 <sysrqb> these are generally how sandboxing is done on these platforms by other projects/applications
15:11:46 <tjr> Gotcha
15:11:49 <sysrqb> and should cover the available sandbxing techniques for all supported platform versions
15:12:01 <GeKo> android = linux here?
15:12:32 <sysrqb> on android, there is a default per-app sandbox, so apps are isolated from each other (to a large extent)
15:12:46 <tjr> There's also the Windows and OSX hypervisor-based solutions; but as you noted Windows requires a pro version; and I don't know anything about OSX's
15:13:27 <sysrqb> but we'll want some isolation within our app, as well, and that is accomplished by using background "services" (think similar to a daemon)
15:13:56 <sysrqb> and communication between services and the foreground app is done using a built-in IPC protocol
15:14:29 <sysrqb> services can be restricted to only computation, without any file system, networking, or device access
15:15:11 <sysrqb> right, on OS X, we may be able to use a hypervisor-based solution, as well
15:15:57 <sysrqb> but that is much more complex than the existing "seatbelt" model
15:16:31 <sysrqb> one problem with seatbelt is the problem with nesting seatbelt profiles
15:16:50 <sysrqb> as in, adding additional restrictions onto an existing enabled seatbelt profile
15:17:09 <sysrqb> i'm not sure if anyone has found a way of doing this yet
15:17:19 <tjr> Yes, that is a problem
15:17:36 <tjr> I there was something about safari there let me see if i can find it, but i don't think it was promising....
15:18:47 <tjr> Okay yea I believe Safari has a 'parent' process that is unsandboxed and all it does it fork off child processes
15:18:57 <tjr> it also forks off a single 'parent' process
15:19:04 <tjr> They apply different profiles
15:19:22 <tjr> I don't know how large the unsandboxed 'real parent' process is
15:19:49 <tjr> This is educated guesswork, but architecturally I think it's doable and what FF would pursue for parent sandboxing absent any change in OSX arch
15:20:22 <sysrqb> also, do you know if i was wrong about using a seatbelt profile and codesigning entitlements together?
15:20:29 <sysrqb> code-signing
15:21:14 <mcs> tjr: So if (for example) a content process is needed, a request somehow goes to the “real parent” ? Interesting.
15:21:25 <tjr> The feedback from Alex and Haik was 'doesn't bother with code signging entitlements, it's the wrong layer of abstraction for a browser sandbox'
15:22:01 <mcs> I don’t remember the details, but when brade and I looked at the entitlement stuff it seemed very coarse-grained and not that useful for a browser.
15:22:01 <tjr> mcs: I would epxect and want to design a model where the 'parent' asks the 'real parent' for a new content process.  Only the 'parent' is in a position to know that a new content process is needed.
15:22:16 <mcs> tjr: got it
15:22:36 <mcs> So the real parent would ideally be very small and auditable
15:22:55 <sysrqb> it seemed like we would be able to remove networking from the browser process entirely using entitlements - only giving networking access to the tor process
15:23:08 <sysrqb> that was my main interest in code signing
15:23:45 <tjr> We already do that with seatbelt though
15:23:49 <tjr> (For the content process)
15:24:31 <sysrqb> true
15:25:22 <sysrqb> one question we may want to think about here is what sandboxing model(s) we want to persue here
15:25:35 <tjr> I think that's the biggest question in my mind :)
15:25:36 <sysrqb> and which model(s) are most likely to be accepted as uplifts
15:25:43 <tjr> I can think of at least three:
15:26:33 <tjr> 1) We use one standard VM on all Desktop OSes, probably Docker or Virtual Box, and run Tor Browser on Linux in a VM
15:26:56 <tjr> 2) We pursue an OS-specific container/virtualization option for each OS
15:27:36 <tjr> 3) We pursue no container/virtualization and instead focus on sandboxing the parent and content processes using OS-specific mechanisms
15:28:30 <tjr> 4) We pick the best option for each OS. (So for Linux, something close to sandboxed-tor-browser, for Windows probably not anything container/vm based)
15:29:03 <tjr> I'm not sure I can think of other (equally high-level) options?
15:29:30 <sysrqb> i think those are the options
15:29:47 <sysrqb> 1) would solve many fingerprintg problems
15:30:26 <sysrqb> but usability would be a problem and the instllation size would be much larger
15:31:26 <GeKo> (fwiw: i had prepared a pad we could use if we want: https://pad.riseup.net/p/sandbox-07-24)
15:31:55 <tjr> I think it owuld be a good idea to identify the criteria with which to evaluate these...
15:31:56 <sysrqb> 2) is probably the easiest, because with this we are expanding on the existing sandboxing in firefox
15:32:02 <sysrqb> yes
15:32:04 <tjr> Maybe.... a) (in the face of a browser exploit) fingerprinting protection b) (no browser exploit) fingerprinting protection c) (in the face of a browser exploit) proxy bypass protection d) user experience e) development effort f) maintainability g) uplift possibilities
15:32:26 <tjr> h) installation size? (part of user experience?)
15:35:18 <liberat2> Ideally in scenario 3, "browser exploits" would be contained to the content process, no?
15:35:23 <sysrqb> i) (no browser exploit) proxy-bypass protection
15:35:34 <tjr> yes, i++
15:35:43 <tjr> liberat2: Not necessarily
15:35:44 <liberat2> So in my mind the question would be whether it's easier to sandbox the content-to-gui interface, or the GUI-to-operating system interface
15:37:02 <tjr> So there's a few routes one can take to a proxy bypass assuming a browser exploit in the content and that the content process blocks network access.
15:37:35 <tjr> You can attack the parent process or another process you're connected to (GPU, compositor, web extension).  So we want to remove network access from those also.
15:37:51 <tjr> You can attack something you're connected to that can talk to the network (which will probably just be tor.exe)
15:37:56 <tjr> Or you can attack the kernel
15:38:35 <sysrqb> i'm actually most concerned about the kernel
15:38:49 <sysrqb> but it's the layer i know the least about on most platforms
15:38:58 <sysrqb> mainly - it's the software we have no control over
15:39:03 <tjr> It is a worthwhile concern to be certain!!!
15:40:44 <sysrqb> but, with that said, sandboxing and hardeneing the sibling/children/parent processes may be the best use of our time right now(?)
15:41:06 <tjr> Ah, perhaps another criteria: time to market with improved security
15:41:19 <sysrqb> ah, good one, yes
15:41:25 <GeKo> what does that mean?
15:42:18 <sysrqb> how quickly can we integrate the sandboxing chosen technique and release it
15:42:34 <sysrqb> err, chosen sandboxing technique(s)
15:42:39 <tjr> What and when can we get something released. e.g. if it takes 3 years to get a VM solution out and we don't really have anything useful before that; vs if we can incrementally deploy security improvements for a child/parent over those three years that each ratchet things a little tighter
15:43:06 <GeKo> sounds like this fits in to the development effort item?
15:43:33 <GeKo> *into
15:44:13 <sysrqb> yes (6)
15:44:44 <GeKo> added
15:45:18 <mcs> The release date could be different for different platforms as well (but we need to have a complete roadmap, I think).
15:45:56 <sysrqb> yes
15:46:29 <sysrqb> when i first began researching this, i was hoping we could have one-single sandboxing design on all the platforms
15:46:47 <GeKo> browser exploit/no browser exploit is concerned with an exploit *anywhere* in the browser not just the content?
15:46:55 <GeKo> or should we split that up?
15:47:06 <sysrqb> so, at least, conceptually, we only needed to think about one design and then use OS-specific functionality for accomplishing it
15:47:15 <tjr> So if we have options and criteria... who/how do we rate these?  (I don't know how well I'd do (11) but I feel pretty good about 1-6, 8, and 10. maybe 7....)
15:47:17 <sysrqb> i'm not sure that's achievalble right now, though
15:47:49 <tjr> GeKo: I would probably break things down in prose talking about the differences and then try to sum things up into a single rating
15:48:21 <GeKo> sounds good. i just don't want to forget about "how much can we trust the parent process" issues
15:49:38 <sysrqb> tjr: slight aside, the Windows-specific launcher logic is already merged into mozilla-central, right?
15:50:05 <GeKo> sysrqb: why do you think that's not achievable?
15:50:07 <tjr> sysrqb: I think it is; but the laucnher is not guaranteed to land/be used.  I expect we'll know by end of Q3 though
15:50:19 <sysrqb> tjr: okay
15:50:33 <tjr> 13:43:39 T<tjr> aklotz: Does 1477790 imply the launcher process is a success and is going to be used; or is it still TBD?
15:50:33 <tjr> 13:43:47 T<tjr> https://bugzilla.mozilla.org/show_bug.cgi?id=1477790
15:50:33 <tjr> 13:43:49 F<firebot> Bug 1477790 — ASSIGNED, aklotz@mozilla.com — Add the ability for firefox.exe to use the launcher process by default
15:50:33 <tjr> 13:44:22 A<aklotz> tjr: No implication yet. Probably going to be a config setting or something like that. But the code has to be there to be able to properly test everything.
15:50:33 <tjr> 13:44:56 A<aklotz> tjr: Though it is a Q3 OKR to make this all work, so we're hoping that the testing looks good
15:52:05 <tjr> GeKo: I agree, I don't think that's fully acheivable. Even if we used option (a) for a VM on all platforms: that won't work on Android. Plus, we'd almost certainly want to apply at least some OS-level sandboxing _to the VM_  so we're now mixing (a) and (c)
15:52:10 <sysrqb> GeKo: i don't think the same sandboxing functionality exists across all platforms, so we can't simply implement a cross-platform abtraction layer
15:53:00 <sysrqb> plus tjr's comment
15:53:11 <GeKo> make sense
15:54:16 <GeKo> so it seems to me we should aim for 4) whatever that means per platform
15:54:23 <GeKo> err
15:54:24 <GeKo> d)
15:54:39 <sysrqb> okay, should we take the current list on the pad and somehow decide on their importance?
15:55:05 <GeKo> you mean of the criteria?
15:55:06 <sysrqb> yes, i think d) will result in the best sandbox per all users
15:55:13 <sysrqb> yes, criteria
15:55:31 <tjr> I think that's a reasonable choice; but it will mean bad scores on uplift possibilities for sure.
15:55:38 <sysrqb> i'm also not sure i know how we should balance/tradeoff those :/
15:55:50 <GeKo> tjr: i am not worried about that per se
15:56:20 <sysrqb> I  an start a thread on the mailing list and we can try discussing it there?
15:56:23 <sysrqb> *can
15:56:31 <sysrqb> for the criteria
15:56:43 <GeKo> wfm
15:56:44 <tjr> Fair enough.  It does let us break this off to be a bit more managable too though. We can say "Bob, you research Windows and give us a report, Alice do Mac, etc."
15:57:10 <GeKo> yep
15:57:15 <sysrqb> Okay, great.
15:57:45 <sysrqb> Okay, I can send another email with a summary of this meeting on tor-dev@
15:57:58 <sysrqb> and then i think we should discuss this topic on tbb-dev@
15:58:08 <sysrqb> sound good?
15:58:32 <GeKo> i think so
15:59:16 <sysrqb> okay - i'll give another minute in case tjr or mcs are typing
15:59:22 <tjr> WFM!
15:59:51 <sysrqb> okay, thanks everyone!
15:59:59 <sysrqb> #endmeeting