darin at apple.com
Tue Feb 1 18:42:00 PST 2011
On Feb 1, 2011, at 6:22 PM, Leonard Rosenthol wrote:
> I guess I am not sure what you are trying to accomplish here then…
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.
This is the same reason that applications run inside a sandbox on iOS, for example.
We want to make it straightforward for plug-in authors to put their plug-ins inside this sort of sandbox.
> I've always been under the impression that the actual "sandboxing of the plugin" (eg. Ensuring that it only does what it is supposed to do) is up to the plugin author - the browser has to "take it at its word" that when it says that it supports the request to run in a "sandboxed frame" that it will do so properly.
> In that regard, the browser needs to inform the plugin as part of the initialization phase that this particular instance is running in a sandbox and here are the restrictions (no-script, etc.) And that's it. After that, life/APIs continues on as before. The plugin will simply adjust its behavior (as does the browser itself!) for that particular content.
The point of putting a plug-in inside a sandbox is so injection of arbitrary code into that plug-in can only do the kinds of things the plug-in was planning to do itself, not all the other bad things that it might want to do to someone’s computer.
> Why is more than that needed?!?!
Due to bugs, there will be vulnerabilities in the plug-in code, just as there are in, say, WebKit code, that can be exploited to run arbitrary code. Running plug-in code inside a sandbox makes it harder for that arbitrary code to do bad things.
More information about the plugin-futures