Re: Electrolysis security

On 8/17/09 5:03 PM, Lucas Adamski wrote:

> I wonder if there's a way for us to eventually verify that there aren't
> direct network calls happening from content processes.  I'm concerned
> about some hacks or special-casing that might have been implemented ages
> ago then forgotten about (such as 307 redirects being a separate code
> path from other redirects).

The eventual security sandbox would prevent the network access in any case.

It's certainly possible for us to say that certain functions may not be
called from a content process and enforce that with runtime aborts, at the
cost of a runtime check, but I can't imagine that the runtime check would be
a problem at least in this case... we don't open sockets in tight loops.

> Regarding file access, could you elaborate a bit on what you mean by
> "only grants access to files"?   Ideally the file download process from
> the dialog-onwards is a parent-only process that does not involve the
> content process at all (other than simple progress updates).  I just

I'm mainly concerned with file uploads. With <input type="file"> you give
the website access to the file data (scriptably even). The model Chromium
uses is similar to this:

content process: fires event when the <input type="file"> browse button is
clicked
chrome process: sees event, pops up file picker (perhaps with an unspoofable
"Select a file to upload to www.example.com dialog text/header)
chrome process: after file is selected, open a file descriptor to the file
and hand it back to the content process, thereby giving the content process
access to the file.

File downloads seem easy to control: the content process either forwards a
download request or actual data to the chrome process, which handles the
data, saving to disk or to a helper application as appropriate.

> I'm not proposing changing the interaction model but just wondering if
> its possible to prevent content processes from throwing native-looking
> dialogs?  For that matter, how much can we restrict content process
> control over the screen.  Could a content process convincingly fake a
> Vista UAC, for example (efficacy of that mechanism aside :) )?

In the security sandbox model the content process has no access to the
screen at all... it only draws to sharedmemory buffers which are then
painted by the chrome process into the browser content area.

All dialogs would be brokered through the chrome process, although that
doesn't necessarily prevent spoofing...

> It should address it insofar we are conscious of what threats we intend
> to address, and which ones we do not.  So long as we can be explicit
> about which threats we will not be trying to mitigate via (later phases
> of) electrolysis.  Given electrolysis touches virtually every part of
> the browser, I'm not sure its threat model is severable from the wider
> browser security model.

So, what do you propose from here? For example, I don't think we should try
to use the multi-process architecture to isolate password/cookie data across
origins. Should it be removed from that list, or explicitly marked as
not-a-goal, or just proposed here for further discussion?

--BDS