14:59:00 #startmeeting sandboxing tor browser 14:59:00 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:25 hi! 14:59:46 * tjr waves 14:59:57 o/ 15:01:27 oh, tjr, is the mojave doc public or should that not be archived? 15:02:06 It's public 15:02:39 okay, i wasn't sure, so i didn't include it in the emails 15:02:42 https://docs.google.com/document/d/13l_XosCmGpf882q-Q63h5ZYuyLr4_r3sWZ0Lf5ZSFCQ/edit# 15:03:04 Google Doc outlining new security/sandboxing features of OS X 10.14 15:03:14 we can take those into consideration, too 15:04:24 maybe one m ore minute and then we can start 15:04:40 small group today 15:05:57 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 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 containerize on all the platforms vs create OS-specific sandboxes 15:07:44 as a quick overview 15:08:24 on Linux, we have - what are now considered - containers: per-process namespace isolation of networking, mounts, IPC, etc 15:08:59 on OS X, we have various filesystem and syscall filtering and restrictions 15:09:57 on Windows, we have privilege reduction and file system/network filtering 15:10:09 (these are not very good desriptions) 15:10:12 This si the current state of sandboxing or the options we have for each platform? 15:10:40 There are more options available on Windows, as well 15:11:13 these are generally how sandboxing is done on these platforms by other projects/applications 15:11:46 Gotcha 15:11:49 and should cover the available sandbxing techniques for all supported platform versions 15:12:01 android = linux here? 15:12:32 on android, there is a default per-app sandbox, so apps are isolated from each other (to a large extent) 15:12:46 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 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 and communication between services and the foreground app is done using a built-in IPC protocol 15:14:29 services can be restricted to only computation, without any file system, networking, or device access 15:15:11 right, on OS X, we may be able to use a hypervisor-based solution, as well 15:15:57 but that is much more complex than the existing "seatbelt" model 15:16:31 one problem with seatbelt is the problem with nesting seatbelt profiles 15:16:50 as in, adding additional restrictions onto an existing enabled seatbelt profile 15:17:09 i'm not sure if anyone has found a way of doing this yet 15:17:19 Yes, that is a problem 15:17:36 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 Okay yea I believe Safari has a 'parent' process that is unsandboxed and all it does it fork off child processes 15:18:57 it also forks off a single 'parent' process 15:19:04 They apply different profiles 15:19:22 I don't know how large the unsandboxed 'real parent' process is 15:19:49 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 also, do you know if i was wrong about using a seatbelt profile and codesigning entitlements together? 15:20:29 code-signing 15:21:14 tjr: So if (for example) a content process is needed, a request somehow goes to the “real parent” ? Interesting. 15:21:25 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 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 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 tjr: got it 15:22:36 So the real parent would ideally be very small and auditable 15:22:55 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 that was my main interest in code signing 15:23:45 We already do that with seatbelt though 15:23:49 (For the content process) 15:24:31 true 15:25:22 one question we may want to think about here is what sandboxing model(s) we want to persue here 15:25:35 I think that's the biggest question in my mind :) 15:25:36 and which model(s) are most likely to be accepted as uplifts 15:25:43 I can think of at least three: 15:26:33 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 2) We pursue an OS-specific container/virtualization option for each OS 15:27:36 3) We pursue no container/virtualization and instead focus on sandboxing the parent and content processes using OS-specific mechanisms 15:28:30 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 I'm not sure I can think of other (equally high-level) options? 15:29:30 i think those are the options 15:29:47 1) would solve many fingerprintg problems 15:30:26 but usability would be a problem and the instllation size would be much larger 15:31:26 (fwiw: i had prepared a pad we could use if we want: https://pad.riseup.net/p/sandbox-07-24) 15:31:55 I think it owuld be a good idea to identify the criteria with which to evaluate these... 15:31:56 2) is probably the easiest, because with this we are expanding on the existing sandboxing in firefox 15:32:02 yes 15:32:04 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 h) installation size? (part of user experience?) 15:35:18 Ideally in scenario 3, "browser exploits" would be contained to the content process, no? 15:35:23 i) (no browser exploit) proxy-bypass protection 15:35:34 yes, i++ 15:35:43 liberat2: Not necessarily 15:35:44 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 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 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 You can attack something you're connected to that can talk to the network (which will probably just be tor.exe) 15:37:56 Or you can attack the kernel 15:38:35 i'm actually most concerned about the kernel 15:38:49 but it's the layer i know the least about on most platforms 15:38:58 mainly - it's the software we have no control over 15:39:03 It is a worthwhile concern to be certain!!! 15:40:44 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 Ah, perhaps another criteria: time to market with improved security 15:41:19 ah, good one, yes 15:41:25 what does that mean? 15:42:18 how quickly can we integrate the sandboxing chosen technique and release it 15:42:34 err, chosen sandboxing technique(s) 15:42:39 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 sounds like this fits in to the development effort item? 15:43:33 *into 15:44:13 yes (6) 15:44:44 added 15:45:18 The release date could be different for different platforms as well (but we need to have a complete roadmap, I think). 15:45:56 yes 15:46:29 when i first began researching this, i was hoping we could have one-single sandboxing design on all the platforms 15:46:47 browser exploit/no browser exploit is concerned with an exploit *anywhere* in the browser not just the content? 15:46:55 or should we split that up? 15:47:06 so, at least, conceptually, we only needed to think about one design and then use OS-specific functionality for accomplishing it 15:47:15 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 i'm not sure that's achievalble right now, though 15:47:49 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 sounds good. i just don't want to forget about "how much can we trust the parent process" issues 15:49:38 tjr: slight aside, the Windows-specific launcher logic is already merged into mozilla-central, right? 15:50:05 sysrqb: why do you think that's not achievable? 15:50:07 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 tjr: okay 15:50:33 13:43:39 T aklotz: Does 1477790 imply the launcher process is a success and is going to be used; or is it still TBD? 15:50:33 13:43:47 T https://bugzilla.mozilla.org/show_bug.cgi?id=1477790 15:50:33 13:43:49 F Bug 1477790 — ASSIGNED, aklotz@mozilla.com — Add the ability for firefox.exe to use the launcher process by default 15:50:33 13:44:22 A 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 13:44:56 A tjr: Though it is a Q3 OKR to make this all work, so we're hoping that the testing looks good 15:52:05 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 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 plus tjr's comment 15:53:11 make sense 15:54:16 so it seems to me we should aim for 4) whatever that means per platform 15:54:23 err 15:54:24 d) 15:54:39 okay, should we take the current list on the pad and somehow decide on their importance? 15:55:05 you mean of the criteria? 15:55:06 yes, i think d) will result in the best sandbox per all users 15:55:13 yes, criteria 15:55:31 I think that's a reasonable choice; but it will mean bad scores on uplift possibilities for sure. 15:55:38 i'm also not sure i know how we should balance/tradeoff those :/ 15:55:50 tjr: i am not worried about that per se 15:56:20 I an start a thread on the mailing list and we can try discussing it there? 15:56:23 *can 15:56:31 for the criteria 15:56:43 wfm 15:56:44 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 yep 15:57:15 Okay, great. 15:57:45 Okay, I can send another email with a summary of this meeting on tor-dev@ 15:57:58 and then i think we should discuss this topic on tbb-dev@ 15:58:08 sound good? 15:58:32 i think so 15:59:16 okay - i'll give another minute in case tjr or mcs are typing 15:59:22 WFM! 15:59:51 okay, thanks everyone! 15:59:59 #endmeeting