Sandbox NPAPI

Brett Wilson brettw at google.com
Tue Feb 1 22:32:18 PST 2011


On Tue, Feb 1, 2011 at 10:15 PM, Ivan Krstić <ike at apple.com> wrote:
> Hi Leonard,
>
> On Feb 1, 2011, at 9:58 PM, Leonard Rosenthol wrote:
>
>> And this can be done either by the browser running the plugin in some form of sandbox (ala Chrome) _OR_ the plugin itself having its own sandbox (ala Adobe Reader).  In the latter case, there is no need for any special API to see this happen (as demonstrated by Reader X today on Windows).
>
> I think we're speaking past each other. If Reader X needed to also run sandboxed on the Mac, how would it implement that sandbox? Mac OS X doesn't expose the requisite sandbox primitives as API. You could use private OS X interfaces like Chrome, but those could change or disappear entirely without any prior notice.
>
> The sole purpose of this API proposal is to provide a cross-platform way of entering a sandbox defined narrowly in terms of filesystem access. This gets plugin writers — at least those who don't need more complex sandbox facilities — out of the business of implementing and maintaining different sandbox implementations for every platform on which they run (tokens pre-Vista, tokens and integrity levels post-Vista, private interfaces on OS X, and so on).
>
>> In the former case, I am not sure I see what API you need either
>
> You need the API to say "I want the OS to restrict my access to resources". On Windows, that API is there today, but the usage complexity is high enough that almost no one has taken on the implementation burden. Chrome and Reader X are among the very few widely-used exceptions; not relying on the OS for sandbox enforcement comes with its own pitfalls (e.g. <http://j.mp/fR0WYZ>).
>
>> SO, that puts you back to #2 - not doing anything in the API and letting it happen at the plugin level.
>
> Plugins are complex and have vulnerabilities. It's not enough for the plugin to want to protect itself from the data it operates on. The OS must also be protected from the plugin.
>
>> Lovely idea, but since you can't control the OS-level APIs that are used by any arbitrary plugin (unless it's a special environment like NaCl), then I simply don't see how you can accomplish this.  And I say this based on the number of APIs that we've had to broker on Windows for Reader.
>
> Complex plugins are not the intended consumers of this API. We're targeting what we believe are the vast majority of simpler plugins that have more modest needs.

My apologies, I've been barely paying attention to this thread when I
noticed this.

I'm actually kind of confused about what you say here. You're
proposing a way to sandbox plugins which is great. But now you're
discarding 99.999% of those installs as being "complex" and not
covered by your proposal (Flash, Reader, Real, QuickTime, Java seem
like they all do various things like printing or want graphics
acceleration, etc). What is an example of one of the "vast majority of
simpler plugins"? Do you imagine NPAPI will be a popular platform for
people writing new plugins that we've not already seen? As one of the
very few people who has written a test NPAPI plugin, I would suggest
that's unlikely.

And even if you imagine random people writing "simpler plugins" why
would they bother opting into some sandbox API when life can be so
much simpler without bothering? The only people interested in putting
the extra work into sandboxing are the large responsible companies
that make "complex" plugins.

Brett


More information about the plugin-futures mailing list