I asked ekr how much this mattered, and he thought it was important. I don't think anyone has pointed me to a documented attack, but it definitely seems like the kind of thing that could be done somehow.
How we allocate domains to content processes is an open question. It's not clear whether we want to segregate high value targets or low value targets. But the infrastructure required is the same either way pretty much. The only strategy we know won't work is round-robin/random, since the attacker could just keep creating domains until they land in the right process. To be clear, I don't think there is very much code complexity here over the normal 2 process (chrome + content) solution. We already have to have process spawning and IPC. The only thing that changes here is code to decide where to spawn new pipelines. Implementation wise, we currently spawn a new process per script thread. I think we should change this to spawn a single, sandboxed content process that contains all the pipelines. Later we can expand this once it's more clear how we should allocate pipelines to processes. jack. On Wed, Aug 3, 2016 at 2:53 AM, Till Schneidereit <t...@tillschneidereit.net> wrote: > I wonder to which extent this matters. I'm not aware of any real-world > instances of the mythical cross-tab information harvesting attack. Sure, in > theory the malvertising ad from one tab would be able to read information > from your online banking session. In practice, it seems like attacks that > gain control of the machine are so much more powerful that that's where all > the focus is. > > Additionally, it seems like two content processes, one for normal sites, > one for high-security ones (perhaps based on EV certificates), should give > much of the benefits. Or perhaps an additional one for low-security ones > such as ads (perhaps based on tracking blocking lists). > > On Wed, Aug 3, 2016 at 5:43 AM, Jack Moffitt <j...@metajack.im> wrote: > >> Each process is a sandboxing boundary. Without security as a concern >> you would just have a single process. A huge next step is to have a >> second process that all script/layout threads go into. This however >> still leaves a bit of attack surface for one script task to attack >> another. How many processes you want is a tradeoff of overhead vs. >> security. >> >> So really it should say "more process more security". >> >> jack. >> >> On Tue, Aug 2, 2016 at 9:09 PM, Patrick Walton <pwal...@mozilla.com> >> wrote: >> > It's not a stupid question :) I actually think we should gather all >> script >> > and layout threads together into one process. Maybe two, one for >> > high-security sites and one for all other sites. >> > >> > Patrick >> > >> > >> > On Aug 2, 2016 6:47 PM, "Paul Rouget" <p...@mozilla.com> wrote: >> >> >> >> On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt <j...@metajack.im> wrote: >> >> >> First, is multiprocess and sandboxing actively supported? >> >> > >> >> > I tested this right before the nightly release, and it was working >> >> > fine and didn't seem to have bad performance. Note that you can run -M >> >> > or -M and -S, but not -S by itself (which doesn't make sense). Also >> >> > note that -M and -S probably don't work on Windows or Android >> >> > currently. >> >> > >> >> >> Is Servo tested with the "-M -S" options? >> >> > >> >> > We do not have automated testing of these yet. >> >> > >> >> >> What's the status of the sandbox? >> >> > >> >> > Should work on Mac and Linux, but hasn't been audited. >> >> > >> >> >> Is there any reasons for these options to not be turned on by >> default? >> >> > >> >> > They should be, although I think we wanted to fix perf issues running >> >> > the WPT suite and get all the platforms working first. We should >> >> > probably test both configurations. >> >> > >> >> >> Do we want to enable "-M -S" for browserhtml? Would that help? >> >> > >> >> > I wanted to have this for the nightly, but didn't have time to test. >> >> > If it works and has decent performance we can switch to having these >> >> > be on. >> >> > >> >> >> I'd like to understand what is not part of the sandboxed content >> >> >> process. >> >> >> I guess compositor code and anything GPU and window related is not >> >> >> sandboxed so it runs in the main process. >> >> >> How does a sync call to localStorage work in a sandboxed process? >> >> >> Where is networking code executed? >> >> > >> >> > The thing that lives in the extra processes (which are sandboxed) are >> >> > the script and layout threads. Right now each script/layout thread >> >> > gets its own process (and I think any pipeline which shares the same >> >> > script thread). >> >> > >> >> > Eventually we'll want to have each extra process contain some number >> >> > of pipelines. So that is script+layout but for arbitrary numbers of >> >> > domains. >> >> >> >> In your slides, you say "more process more better". >> >> That might be a stupid question, but why? >> >> Because of the nature of Servo, can't we just gather all the >> >> script+layout threads into one single sandboxed process? >> >> >> >> > The constellation, networking, graphics, etc all live in the root >> >> > process which has privileges. >> >> > >> >> > >> >> >> I'm trying to understand the relation between a constellation, >> iframes >> >> >> and a sandboxed process. I would naively expect to have one process >> >> >> per constellation, but apparently, it's one process per iframe. If >> I'm >> >> >> not mistaken, today in browserhtml, we have only one constellation. I >> >> >> imagine in the future there would be one sandboxed process per >> >> >> constellation, one constellation per group of tabs of the same >> domain, >> >> >> and one constellation for browserhtml. >> >> > >> >> > There is only one constellation. A constellation owns a set of >> >> > pipelines which then form a tree of pipelines. It is only these >> >> > pipelines that live outside the main process. >> >> >> >> Would there be any advantage of having one constellation per tab? >> >> Can't a constellation fail? Would it be more robust to have multiple >> >> constellations? >> >> >> >> I've read somewhere that a constellation should be seen as the set of >> >> pipelines per tab. >> >> >> >> But maybe it's a different story with browserhtml because what would >> >> hold the tabs/constellations would be a pipeline, so at the end, it's >> >> just doesn't make sense to have multiple constellations. >> >> >> >> Asking because if multiple constellation is better and if that's we >> >> eventually want to do, we need to rethink bhtml architecture. >> >> >> >> > Eventually we'll probably experiment with where resource caching >> >> > threads and such go. >> >> > >> >> > Here's a link to the deck I presented in London which has pretty >> >> > pictures of what the design should be: >> >> > >> >> > >> https://docs.google.com/presentation/d/1ht96DBAynx7dbL2taDAzNHs78QWeKvyzrVV1O-cDQLQ/edit?usp=sharing >> >> > >> >> > jack. >> >> _______________________________________________ >> >> dev-servo mailing list >> >> dev-servo@lists.mozilla.org >> >> https://lists.mozilla.org/listinfo/dev-servo >> _______________________________________________ >> dev-servo mailing list >> dev-servo@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-servo >> > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
