justinschuh

> The network stack has been out of the content process for a super long time, it is not a new thing.

FWIW, Chrome's network stack doesn't live in the content process either. It's not currently sandboxed, but it's in a process that has no scripting runtime or other dynamic content, so it's still pretty high bar for exploit. The exact reasons for the current situation have to do with some legacy Windows support that has since been removed, which is why the sandboxing work is now moving forward. So, I definitely appreciate your situation with adding some sandbox exceptions for WebRTC.

> I suspect over time we'll see our respective sandbox models become more similar over time, especially on macOS.

Fair. But I will say that Chrome being cross-platform tends to naturally push us in the direction of eliminating sandbox attack surface. Our supported platforms just differ so much that it's easiest to lock down the OS as much as possible and implement narrower, origin-bound capability brokers inside Chrome. If I were more tightly bound to a given OS implementation, I expect I'd have a lot more fights about sandboxing, because it's easier for devs to just standardize on what the OS gives you.

I don't keep up too much on Safari these days, so congrats on moving the network stack out of the content process. But looking at the current WebProcess seat-belt policy and what gets initialized, it looks like there's still far too much attack surface relative to Chrome. Things like audio/video capture and other permissioned Web APIs appear to be permitted directly inside the sandbox. And the GPU attack surface alone is a giant vector for escape--plus all the other potential escape vectors posed by that very long list of mach services.

So yeah, the seat belt policies alone aren't determinative, which is why I called them "a rough analog". And it's hard to say what gets pulled in through warmup (which is why we'll be eliminating it with our v2 bootstrap sandbox). Accepting that, it's pretty clear that there's just dramatically less attack surface exposed from inside Chrome's sandbox versus Safari's.

Indeed. Fixed now, and thanks for letting me know.

So, the thing we call "win32k lockdown" on Chrome is just a term for the various things we had to do to enable ProcessSystemCallDisablePolicy on our sandboxed renderer processes (the processes that handle Web content). ProcessSystemCallDisablePolicy is a very big hammer, because enabling it prior to process launch means the kernel blocks all GDI and NTUser calls, such that the process can't interact with the UI or graphics subsystems. Chrome can do this because our UI and graphics acceleration layer is split into our unsandboxed browser process and the more weakly sandboxed GPU process.

The difference with Edge and IE is that they run their UI and graphics stack in their content processes, which are an analog to Chrome's renderer processes. However, any UI on Windows requires win32k kernel support, so they can't disable it like Chrome does. Instead, Edge uses its win32k filter to limit the attack surface to only the calls that they need. So, where Chrome's architecture allowed us to make an aggressive cut, Microsoft is instead working to iteratively shut off the same attack surface in Edge.

And yes, the win32k whitelist is currently restricted to EdgeHTML processes by the kernel and signature enforcement. I know this because we currently sandbox our GPU process at about the same level as an IE content process, and we wanted to use the win32k whitelist get the same improvements as Edge. Unfortunately, Microsoft is still working on the capability, and is not ready to expose it to third-parties yet (but has given signs they may be willing to do so in the future).

Source: I lead engineering on Chrome security and am the original architect of Chrome's win32k lockdown.

Yup. Our only closed source bits at this point are Flash and the Widevine CDM (DRM), both of which can be disabled from: Settings -> Content Settings.

Really? Repeatedly? So, I'm sure you can produce a citation to this effect?

> when riseup.net got an NSL to give access to the email accounts

This is simply not true. An NSL cannot be used to compel access to any communication content—and certainly not control of an account; they're limited solely to metadata (e.g. phone call records, IP addresses, billing metadata, etc.). I'm not a fan of NSLs, and strongly support repealing the section 505 expansion, but it behooves no one to lie about what an NSL is and what it can compel.

No worries. :)

I think you may be confused about who you're replying to and what subject you're replying on.

I think we've seen it once so far, for a Flash exploit that didn't have a sandbox escape in Chrome.