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

What line of code ought I to write instead of that one in order to
avoid introducing a security vulnerability?

Adam


On Tue, Jan 26, 2010 at 7:36 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 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:50:18 UTC