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

[Ben Laurie]

On Tue, Sep 2, 2008 at 9:10 PM, Jed Donnelley <capability at webstart.com> 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).
>>
>>Does anyone know any more details, such as how the sandboxing works on
>>Linux?
>
> 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.

Since we're getting asked this a fair amount, I'm afraid I have a
canned response:

"Speaking for the Caja team, Caja is designed to work with whichever
browser the user has, so Chrome is currently another browser we
support. Whilst we would love for every piece of JavaScript to use
Caja to improve security, this is not practical without cooperation.
Firstly, not all JavaScript can be compiled by Caja, so some (minor,
we hope) edits might be required before things will compile at all.
Secondly, Caja improves security by allowing decisions to be made
about what scripts can do - but someone has to make those decisions.
Currently, Caja is using gadgets as its first target, particularly
OpenSocial gadgets. Because the functionality we want to make
available to OpenSocial gadgets is fairly clearly understood, we can
allow the OpenSocial container to restrict access to only that
functionality. We are some way off being able to do the same thing for
arbitrary web scripts - and indeed, it is unlikely that Caja will be
able to address any but the most basic security concerns without some
intervention by programmers.

The Caja team very much looks forward to working with the Chrome team
(and any other browser vendor) to widen the coverage of Caja, but we
must first walk before we run. Both Chrome and Caja are at the
beginning of that process."

>  Section 4 of the comic deals directly
> with security issues:
>
> http://books.google.com/books?id=8UsqHohwwVYC&printsec=frontcover#PPA25,M1
>
>
>
> 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?
>
> 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?

Chrome only runs on two OSes. Vista and XP. Mentioning one of them
doesn't seem that odd.

> 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).
>
> 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?
>
> 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.
>
> 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?  Is that work complete or did some
> work on it get done but the project remained incomplete?
>
> 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?

Broad comment on POLA and plugins: if you want to use POLA for
plugins, then you need an environment that supports it. There aren't
many candidates. E? Caja? Joe-E?

>
>
> Finally there's the question about the relationship between
> Firefox and Chrome?  Is there any?  If not, why not?
>
> --Jed  http://www.webstart.com/jed-signature.html
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>