On Wed, Aug 3, 2016 at 12:38 PM, David Bruant <[email protected]> wrote:
> Le 03/08/2016 à 18:47, Andrew McCreight a écrit : > > In a world where a sophisticated attacker can get root privileges, I >> wouldn't spend too much time worrying about intraprocess attacks. > > If (safe) Rust holds its promises of preventing use-after-free, > uninitialized stack variables, out-of-bounds, etc, then the attacks > demonstrated at pwn2own are... not possible at all (modulo OS vulns). > And then the security discussion needs to start over at a new starting > point, in this new world where these attacks are not possible at all. > Maybe intra-process attacks are the most worrisome threat in this new > world... > If arbitrary code execution in a content process is not possible, than intra-process attacks are also very hard (you are probably limited to things like race conditions). I think it is a question of what you do when you can run anything in the child process: do you attack the OS sandbox (which as you noted Servo can't really do anything about) or do you try to, say, grab the cookies for another site? > > My undertanding of pwalton's email is that the parts written in unsafe > rust binding to complex C++ libraries should be bundled together in their > own process(es). > Were the JS and layout engines written in safe Rust, I don't think > process-as-a-sandoxing-boundary would be necessary? > > David > > [1] http://fr.slideshare.net/BrendanEich/future-tense-7782010#14 > [2] https://air.mozilla.org/overview-of-research-team-projects/ (starting > at 55'0'') > > > If you do want to think about it, I'd first read over the work that Chrome >> people have already put into thinking about this issue: >> http://www.chromium.org/developers/design-documents/site-isolation >> >> I'm not sure how much they have actually shipped from this initiative, >> though. >> >> Andrew >> >> [1] >> >> http://venturebeat.com/2016/03/18/pwn2own-2016-chrome-edge-and-safari-hacked-460k-awarded-in-total/ >> >> >> 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 >>> <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>> 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" <[email protected]> wrote: >>>>>> >>>>>>> On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt <[email protected]> >>>>>>> >>>>>> 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 >>>>>>> [email protected] >>>>>>> https://lists.mozilla.org/listinfo/dev-servo >>>>>>> >>>>>> _______________________________________________ >>>>> dev-servo mailing list >>>>> [email protected] >>>>> https://lists.mozilla.org/listinfo/dev-servo >>>>> >>>>> _______________________________________________ >>>> dev-servo mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-servo >>>> >>> _______________________________________________ >>> dev-servo mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-servo >>> >>> _______________________________________________ >> dev-servo mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-servo >> > > > _______________________________________________ > dev-servo mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list [email protected] https://lists.mozilla.org/listinfo/dev-servo
