lrosenth at adobe.com
Tue Feb 1 21:58:25 PST 2011
>If a malicious site tricks a plug-in into executing arbitrary code by exploiting a buffer overrun, for example, running the >plug-in code inside a sandbox makes it so that the bad guys' code can't do things like read or write arbitrary places in the >file system.
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). In the former case, I am not sure I see what API you need either - UNLESS you expect the browser to also provide the broker process and the associated IPC...but if you do that, then you need (as Adam mentioned) a VERY complete set of APIs that would cover any/all possible things that would need to be brokered. And I don't see how you could come up with that list. SO, that puts you back to #2 - not doing anything in the API and letting it happen at the plugin level.
>We want to make it straightforward for plug-in authors to put their plug-ins inside this sort of sandbox.
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.
However, I see my concern as being one that needs to be addressed as part of the language changes for HTML(5). With the addition of the sandbox attribute on the IFrame, there is no way for a plugin to participate EVEN IF it wanted to by obeying the allow/not-allow rules. Thus Adobe's interest (and I would hope Apple's with QT) would be to ensure that our plugins is to see NPAPI updated to provide the necessary information so that our (OS-level sandboxed plugins) can participate in all parts of the web.
More information about the plugin-futures