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