[cap-talk] Google Chrome - web browser with sandboxed rendering

[David-Sarah Hopwood]

Jed Donnelley wrote:
> At 10:37 AM 9/2/2008, Mark Seaborn wrote:
>> Apparently Google are developing a web browser called Chrome in which
>> each tab runs in a separate process, sandboxed at the OS level.
>>
>> Unusually, the introductory material is in the form of a comic strip:
>> http://www.google.com/googlebooks/chrome/index.html
>> - pages 25-31 cover sandboxing (I can't see a way to link to
>> individual pages).

<http://blogoscoped.com/google-chrome/25>

>> Does anyone know any more details, such as how the sandboxing works on
>> Linux?

Chrome has not yet been released for Linux:
<http://dev.chromium.org/developers/faq>
<http://dev.chromium.org/developers/how-tos/build-instructions-linux>

According to
<http://dev.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ>,

# Currently the sandbox library is available only on Windows, but we plan
# to release equivalent functionality for the other platforms on which
# Chromium is being developed.

It appears that the Windows implementation is using an approach basically
similar to Polaris, in the sense that they're relying on Windows security
mechanisms to restrict sandboxed processes (including using the integrity 
level mechanism [1] when running on Vista). Unlike Polaris, however,
they're not making any attempt to support legacy code in a sandboxed
process -- to the extent that they are prepared to break widely used
Windows functionality, such as COM -- so the permissions on the sandbox
account can be much tighter.

It seems as though sandboxed processes must share a user account for
efficiency reasons, though, since creating a user account for each
browser tab [2] clearly isn't practical. If so, then this imposes some
limits to how far sandboxed processes can be isolated from each other.
(I am happy to see, however, that each process is run on a different
Windows "Desktop". That is the kind of design detail that gives me some
confidence that the developers have thought about potential attacks
and basically know what they are doing. It is not clear whether they
are also run in different "Job"s.)


[1] As pointed out in
     <http://msdn.microsoft.com/en-us/library/bb625957.aspx>, Vista's IL
     mechanism does not implement the Biba model's no-read-down restriction,
     and so the description of it as similar to Biba may be more misleading
     than useful.

     In any case, the Biba model and Vista's IL model are both hopelessly
     inexpressive: because they assume that integrity levels can be
     totally ordered, they are unable to express the simple policy that
     two processes should be unable to affect each other's integrity.

     In fact, since the IL mechanism is not claimed to provide a security
     boundary (see
<http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx>),
     it is unclear whether it is capable of enforcing any security policy
     whatsoever (either on its own or combined with other Windows security
     mechanisms).

[2] Actually the separation into processes is not always per-tab; see
     <http://dev.chromium.org/developers/design-documents/process-models>

> I'd also be interested to start a discussion with anything anybody
> knows about the Google Chrome browser.  I've read the comic (above)
> and will share a couple of notes that interested me below.
> 
> I would like to hear about any relationship between the Google
> Chrome browser and Caja.  Section 4 of the comic deals directly
> with security issues:
> 
> http://books.google.com/books?id=8UsqHohwwVYC&printsec=frontcover#PPA25,M1

They are independent projects. Chrome (and its V8 JavaScript implementation)
isn't one of the browsers that Caja is currently tested on. I've submitted
a Caja enhancement request that it should be:
<http://code.google.com/p/google-caja/issues/detail?id=725>

> 1.  When they say (page 26:
> 
> http://books.google.com/books?id=8UsqHohwwVYC&printsec=frontcover#PPA26,M1
> 
> ) that they've taken the existing process boundary and made it a jail,
> how?  Are the "process"es Windows or Unix processes or something else?
> If something else, what?  If native processes, how have their ambient
> authorities been removed?

They are native processes. See
<http://dev.chromium.org/developers/design-documents/multi-process-architecture> 

for more detail.

Note that the network access is all done by a single process:
<http://dev.chromium.org/developers/design-documents/multi-process-resource-loading>

Since rendering is a much more complicated task than acting as an HTTP
client, that decision is defensible, but it's a compromise that would not
be necessary if properly lightweight protection domains were available.
(The "consistent session state" and "not opening too many connections"
motivations do not by themselves justify using a single process in my view.)

> 2.  At the bottom right of page 27:
> 
> http://books.google.com/books?id=8UsqHohwwVYC&printsec=frontcover#PPA27,M1
> 
> there is an explicit reference to Vista, "vista uses a modified version
> of the biba security model which uses three levels."  Doesn't it seem a
> bit odd that Vista would be referenced specifically as an OS - even beyond
> the more generic "Windows" - but that no other operating systems are
> referenced?

Not really, given that the sandboxing is only currently implemented for
Windows, and uses the Vista integrity level mechanism when running on Vista.

> 3.  At the top of page 29:
> 
> http://books.google.com/books?id=8UsqHohwwVYC&printsec=frontcover#PPA29,M1
> 
> there is a perfect place for a discussion of POLA (only give the
> application what it needs - "none" isn't the right answer).

A sandboxed process has full permissions (in the web browser user's account)
until it is "locked down". That allows it to open arbitrary Windows HANDLEs
which can still be accessed in the locked-down state.

This has some disadvantages, but I can see the pragmatic benefits. The 
equivalent mechanism on Unix has been found to be quite error-prone, but
that is partly due to misdesign of the relevant Unix APIs, and I don't know
whether those design flaws also apply to the 'LowerToken' API (about which
I have been unable to find any technical information).

> 4.  The discussion of plugins (also starting on page 29 at the bottom)
> suggests that dealing with them (running them securely) is an
> unsolved problem.  The comic says that with some help from plugin
> makers they can reduce the trust that plugins need.  Might this be
> an opportunity for POLA?

Obviously, but the sandboxing approach they are using on Windows is liable
to break all but the simplest libraries (for example the FAQ states that
Winsock, COM, and DirectX can't be used from sandboxed processes, and I
doubt that there are any plugins that don't rely to some extent on COM).

Perhaps some of the experience from Polaris could be applied to the problem
of running plugin processes with less authority (presumably with one user
account per installed plugin). But Polaris is not open-source, so there's
no chance of code re-use unless and until it is.

> Still, the comic then says:
> 
> 5.  on Page 30:
> 
> http://books.google.com/books?id=8UsqHohwwVYC&printsec=frontcover#PPA30,M1
> 
> "meanwhile we have a huge surface area reduction from all this --
> <pointing up - suggesting all the rendering and other active browser
> content> to this <holding a seemingly innocuous plugin in hand>.
> 
> Of course if the only vulnerabilities are left in the plugins, that
> is where the attacks will come.

Yes. OTOH, without support for plugins, Chrome would be considered usable
by far fewer people. I would still use it, but I'm probably in a tiny
minority.

> 6.  On page 31 (top right):
> 
> http://books.google.com/books?id=8UsqHohwwVYC&printsec=frontcover#PPA31,M1
> 
> there is what seems to me a rather odd use of the first person
> singular in a reference to seemingly incomplete work, "so I
> worked on ripping plugins out of the rendering process
> and putting them in a separate process all their own."
> 
> Who is the "I" in the above?

Apparently John Abd-El-Malek (see page 25).

> Is that work complete or did some
> work on it get done but the project remained incomplete?

I don't know whether it is fully implemented, but the
<http://dev.chromium.org/developers/design-documents/plugin-architecture>
seem to describe an essentially complete design.

I would suggest asking questions like this on the chromium-discuss list:

<http://dev.chromium.org/developers/discussion-groups>
<http://groups.google.com/group/chromium-discuss>

(John Abd-El-Malek personal email address is not difficult to find out,
but it's generally better to address questions about a project to its
mailing list than to individual developers.)

> 7.  Regarding the "gears" Web API standard, e.g. as on page 35:
> 
> http://books.google.com/books?id=8UsqHohwwVYC&printsec=frontcover#PPA35,M1
> 
> what about POLA and the solution to the plugin problem?

I don't see how this relates to plugins at all. Plugins are written as
native code, and depend heavily on accessing native OS APIs; the code in
a Gears application is JavaScript.

> Finally there's the question about the relationship between
> Firefox and Chrome?  Is there any?  If not, why not?

Firefox is not a Google project. But Chrome is mostly 3-clause BSD-licensed
<http://code.google.com/chromium/terms.html>, so there should be no
obstacle to reusing Chrome code in Firefox from a licensing point of view.
However, Firefox does not use WebKit, so I'm not sure how much actual
code from Chrome would be reusable in Firefox.

 From a technical point of view I think the choice of starting essentially
from scratch, but by minimally forking an existing rendering engine, is a
good design decision for Chrome. I have no direct experience with WebKit,
but it seems like the criteria they used to assess rendering engines
are the right ones.

-- 
David-Sarah Hopwood