Sandbox NPAPI

Maciej Stachowiak mjs at apple.com
Wed Feb 2 18:20:09 PST 2011


On Feb 2, 2011, at 6:10 PM, Jethro Villegas wrote:

> Yes, we'd like the flexibility to choose what we broker and not have multiple pass-through functions in NPAPI. I do think we'll need an API for the process spawning so that the process is a child of the browser (and not the plug-in which would be running low-privilege.)

Is there a reason the plugin can't spawn the broker before entering the sandbox, while it still has high privileges? As far as we can tell, this would work fine, even in Chrome's sandboxing model.

Regards,
Maciej

> 
> JV
> 
> -----Original Message-----
> From: plugin-futures-bounces at mozilla.org [mailto:plugin-futures-bounces at mozilla.org] On Behalf Of Leonard Rosenthol
> Sent: Wednesday, February 02, 2011 5:59 PM
> To: Maciej Stachowiak; Brett Wilson
> Cc: Darin Adler; plugin-futures at mozilla.org
> Subject: RE: Sandbox NPAPI
> 
> If a plugin is going to have to write a broker for everything else anyway, why special case the file operations?  If I have to write a broker, then I am broker my own file calls since I have more control over them and a common implementation for brokering OS APIs.  Otherwise, I have to do completely differently, and that doesn't seem productive to implementation and testing.
> 
> So I would favor removing the file system "callbacks" and keeping it pretty simple...
> 
> Leonard
> 
> -----Original Message-----
> From: plugin-futures-bounces at mozilla.org [mailto:plugin-futures-bounces at mozilla.org] On Behalf Of Maciej Stachowiak
> Sent: Wednesday, February 02, 2011 2:34 PM
> To: Brett Wilson
> Cc: Darin Adler; plugin-futures at mozilla.org
> Subject: Re: Sandbox NPAPI
> 
> 
> On Feb 1, 2011, at 10:32 PM, Brett Wilson wrote:
> 
>>> 
>> 
>> 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.
> 
> I think you're misunderstanding what Ivan is saying. The API proposal *is* sufficient to cover all of the plugins you mention. However, they'll have to use their own means to perform privileged operations, either by acquiring necessary resources before entering the sandbox, or by launching a "broker" process and setting up an IPC pipe to it before entering the sandbox.
> 
> What Ivan is saying is, for the subset of plugins where file access is the primary privileged operation they need, the special provisions in the API for files provide for that without the need to specially pre-acquire resources or use a broker.
> 
> My understanding is that this is very similar to Google and Adobe's work on sandboxed Flash for Chrome - the plugin enters a sandbox and uses a broker for privileged operations.
> 
> The key differences are:
> 
> (A) We don't provide an API to get the browser to launch a privilege broker process and manage IPC to it, since it seems like this is something the plugin can do for itself (and it's very hard to make a portable API that provides all the IPC facilities that might be needed).
> 
> (B) We provide direct provisions for filesystem access, since we think this will be a common need.
> 
> We'd like to refine this API and get it going. We think it's critical to have a cross-browser solution for plugin sandboxing, and soon. If it would help, we can implement the proposal in Safari and port a plugin to it, before coming back for further discussion. Hopefully that will reduce the skepticism over whether this approach is workable. We hoped to get rough consensus before proceeding with implementation, but it seems like this may create a chicken-and-egg problem.
> 
> Regards,
> Maciej
> 
> _______________________________________________
> plugin-futures mailing list
> plugin-futures at mozilla.org
> https://mail.mozilla.org/listinfo/plugin-futures
> _______________________________________________
> plugin-futures mailing list
> plugin-futures at mozilla.org
> https://mail.mozilla.org/listinfo/plugin-futures



More information about the plugin-futures mailing list