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

On Tue, Jan 26, 2010 at 8:53 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> Then you need to block the GEARS plugin.  I have no problem with that.

I don't think we want to play whack-a-mole with the long tail of
browser plugins.

> But that code also blocks any number of perfectly valid, and sandbox safe, plugins.

So?  Many security checks block lots of things that are safe.

> It also doesn't address the issue that some non-plugin-based format should be restricted because it could open up XSS (or other) vulns and this solution does NOT solve it.

If there's some code in the browser that violates the sandbox security
model, I'll fix it.  The problem is I can't fix the Gears plugin
because it's in my codebase.

> Rather than throwing out (segregating? Ostracizing?) an entire class of technology due to a few "bad apples" - why don't we try to solve the actual problem?!?!  (and that's MY point that you clearly don't see to grok)

That line of code does solve the actual problem.

The long term solution is to let plugins participate in the sandbox
security model and then add an allow-plugins directive that re-enables
them, which is where this thread started N thousand words ago.

Adam


> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Tuesday, January 26, 2010 9:50 PM
> To: Leonard Rosenthol
> Cc: Maciej Stachowiak; public-html@w3.org
> Subject: Re: What defines a "plugin"? WRT sandboxing?
>
> Leonard,
>
> I'm tired of explain this issue to you.  If I remove that line of
> code, the Gears plugin will allow the sandboxed content to access the
> databases for the non-sandboxed version of the origin.  That is the
> proximate security vulnerability.
>
> Adam
>
>
> On Tue, Jan 26, 2010 at 8:46 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> You are ASSUMING that it is a security vulnerability...hence the reason we can't agree.
>>
>> -----Original Message-----
>> From: Adam Barth [mailto:w3c@adambarth.com]
>> Sent: Tuesday, January 26, 2010 8:49 PM
>> To: Leonard Rosenthol
>> Cc: Maciej Stachowiak; public-html@w3.org
>> Subject: 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 21:02:14 UTC