RE: What defines a "plugin"? WRT sandboxing?

That code is an implementation on the current PROPOSED text for how sandboxing should work.

I am suggesting that there is a BETTER WAY to implement sandboxing with respect to content types.  

But since you seem to believe that the spec can't be changed - it makes it difficult to discuss.

Leonard

-----Original Message-----
From: Adam Barth [mailto:w3c@adambarth.com] 
Sent: Tuesday, January 26, 2010 6:07 PM
To: Leonard Rosenthol
Cc: Maciej Stachowiak; public-html@w3.org
Subject: Re: What defines a "plugin"? WRT sandboxing?

Regardless of whether my argument is "specious," WebKit needs to
include this line of code or else it will contain a security
vulnerability:

http://trac.webkit.org/browser/trunk/WebCore/loader/FrameLoader.cpp#L1281

You can dance around the issue all you like, but those are the facts
on the ground.

Adam


On Tue, Jan 26, 2010 at 4:58 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> I completely understand why, today, plugins are an easy scapegoat for what is clearly a larger issue concerning preventing unexpected behavior in a "sandboxed" environment.
>
> However, you seem to be missing my point.  That the issue is _NOT_ plugins - the issue is the content involved - regardless of where it comes from.
>
> How many emails you have to send is a specious argument.  We're talking the proper implementation of a technology....
>
> Leonard
>
> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Monday, January 25, 2010 11:22 PM
> To: Leonard Rosenthol
> Cc: Maciej Stachowiak; public-html@w3.org
> Subject: Re: What defines a "plugin"? WRT sandboxing?
>
> On Mon, Jan 25, 2010 at 9:24 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> What exactly are we trying to prevent?
>
> We're trying to prevent malicious content from leveraging plug-ins to
> escape the security restrictions imposed by @sandbox.  Presently,
> there exist a great many plug-ins that do not understand the sandbox
> security model and therefore would allow sandboxed content to
> circumvent the restrictions of the sandbox.  Therefore, the only safe
> course of action is to prevent sandboxed content from interacting with
> these plug-ins.
>
> To answer your specific question, if Safari allowed sandboxed content
> to instantiate a QuickTime <video> that circumvented the sandbox
> security model, I would email security@apple.com and they would issue
> a patch to fix the vulnerability.  If Safari allowed sandboxed content
> to instantiate a Gears <object> that circumvented the sandbox security
> model, I can either email security@apple.com or security@google.com.
> If I email security@apple.com, there's not much they can do except
> prevent the content from instantiating Gears.  If I email
> security@google.com, there is not much they can do short of preventing
> Gears from being used by all content.  Instead of waiting for the
> vulnerability to be reported in a shipping product, we're fixing the
> vulnerability in the specification by doing what security@apple.com
> would have to do anyway.
>
> Adam
>

Received on Tuesday, 26 January 2010 19:36:39 UTC