Re: Electrolysis security

On 8/21/09 3:02 PM, Lucas Adamski wrote:

> Regarding the point below, I said there it would reduce
> platform-specific code in the content process, which means we don't end
> up with multiple copies of that around.  Regarding context switching, we

The content and chrome processes have the exact same code (they are the same
binary). Differences in behavior are due entirely to runtime switches.

> chrome process.  Since the proposed model involves passing native file
> handles/descriptors, it requires the content process to have access to
> all of the usual file I/O libraries and prevents us from trying to
> whole-sale break those, and rely instead on ensuring that content
> processes can't load anything by direct or indirect references, can't
> import libraries that would allow them to do so, etc.  Now it may not be
> possible to disable these wholesale because, as Zack mentioned, a bunch
> of libc assumes access to certain public files.  But its a worthy goal. :)

The security sandbox places the responsibility for preventing access on the
OS, not on any libraries. The content process can load any library that it
wants (assuming it has access to read that file at all), but that doesn't
give it any permissions to OS resources.

> My take-away from the chrome security model is that identifying and
> patching the various libraries to prohibit access to bad stuff is a
> painful game of whack-a-mole.

The chrome security sandbox uses the opposite system: they disallow
everything by default, and then patch a few functions to *allow* access that
would otherwise be disallowed (by remoting the request and duplicating
handles). In general it seemed that we wouldn't need to do any of this
patching... it was mainly only used for plugins, which neither Chrome or us
are sandboxing in the near future.

--BDS