Linux: initialize the sandbox in the Plugin process.

Linux: initialize the sandbox in the Plugin process.

We don't have a policy for plugin processes so we apply a basic
blacklist. It's unlikely that we'll do much more in the future.

BUG=

[jln (very slow on Chromium), 2012-09-01 00:34:59]

Hello Antoine,

this is part of an effort to make sure that all processes start the sandbox on
Linux.

I'm doing this in PluginMain() to be consistent with what happens for other
process types.

[jln (very slow on Chromium), 2012-09-01 00:35:59]

On 2012/09/01 00:34:59, Julien Tinnes wrote:
> Hello Antoine,
> 
> this is part of an effort to make sure that all processes start the sandbox on
> Linux.
> 
> I'm doing this in PluginMain() to be consistent with what happens for other
> process types.

(sorry, re-sending with correct subject)

[piman, 2012-09-01 00:37:14]

I'm confused - plugins can't be loaded in the sandbox.

[jln (very slow on Chromium), 2012-09-01 00:49:27]

On 2012/09/01 00:37:14, piman wrote:
> I'm confused - plugins can't be loaded in the sandbox.

I saw that Windows supported trying to sandbox some plugins. I didn't
investigate this mechanism yet.

I just wanted to make sure that InitializeSandbox() was called for Linux for
every process type.

At the moment, for plugins, we don't do much (I applied the small blacklist
policy that blacklists ptrace, maybe even that is too much and I should use
AllowAll ?).

[Jorge Lucangeli Obes, 2012-09-01 01:16:47]

On 2012/09/01 00:49:27, Julien Tinnes wrote:
> On 2012/09/01 00:37:14, piman wrote:
> > I'm confused - plugins can't be loaded in the sandbox.
> 
> I saw that Windows supported trying to sandbox some plugins. I didn't
> investigate this mechanism yet.
> 
> I just wanted to make sure that InitializeSandbox() was called for Linux for
> every process type.
> 
> At the moment, for plugins, we don't do much (I applied the small blacklist
> policy that blacklists ptrace, maybe even that is too much and I should use
> AllowAll ?).

Chatted with Antoine about this. The plugin process loads NPAPI plugins which do
not expect to be restricted in any way. If we want to have the plugin process go
through InitializeSandbox for consistency, we should enable the AllowAll policy.

Even in that case, it's not crazy to think about the plugin process as hopeless
and special and keep it out of the InitializeSandbox path altogether.

[jln (very slow on Chromium), 2012-09-01 01:26:48]

On 2012/09/01 01:16:47, Jorge Lucangeli Obes wrote:
> On 2012/09/01 00:49:27, Julien Tinnes wrote:
> > On 2012/09/01 00:37:14, piman wrote:
> > > I'm confused - plugins can't be loaded in the sandbox.
> > 
> > I saw that Windows supported trying to sandbox some plugins. I didn't
> > investigate this mechanism yet.
> > 
> > I just wanted to make sure that InitializeSandbox() was called for Linux for
> > every process type.
> > 
> > At the moment, for plugins, we don't do much (I applied the small blacklist
> > policy that blacklists ptrace, maybe even that is too much and I should use
> > AllowAll ?).
> 
> Chatted with Antoine about this. The plugin process loads NPAPI plugins which
do
> not expect to be restricted in any way. If we want to have the plugin process
go
> through InitializeSandbox for consistency, we should enable the AllowAll
policy.
> 
> Even in that case, it's not crazy to think about the plugin process as
hopeless
> and special and keep it out of the InitializeSandbox path altogether.

Yeah, I don't feel very strongly about this. The one use case I could imagine
would be to do something for the GoogleTalk plugin.

But as I had noted in the commit message, it's unlikely that we would spend the
time actually doing anything.

[jln (very slow on Chromium), 2012-09-01 01:30:53]

On 2012/09/01 01:26:48, Julien Tinnes wrote:
> On 2012/09/01 01:16:47, Jorge Lucangeli Obes wrote:
> > On 2012/09/01 00:49:27, Julien Tinnes wrote:
> > > On 2012/09/01 00:37:14, piman wrote:
> > > > I'm confused - plugins can't be loaded in the sandbox.
> > > 
> > > I saw that Windows supported trying to sandbox some plugins. I didn't
> > > investigate this mechanism yet.
> > > 
> > > I just wanted to make sure that InitializeSandbox() was called for Linux
for
> > > every process type.
> > > 
> > > At the moment, for plugins, we don't do much (I applied the small
blacklist
> > > policy that blacklists ptrace, maybe even that is too much and I should
use
> > > AllowAll ?).
> > 
> > Chatted with Antoine about this. The plugin process loads NPAPI plugins
which
> do
> > not expect to be restricted in any way. If we want to have the plugin
process
> go
> > through InitializeSandbox for consistency, we should enable the AllowAll
> policy.
> > 
> > Even in that case, it's not crazy to think about the plugin process as
> hopeless
> > and special and keep it out of the InitializeSandbox path altogether.
> 
> Yeah, I don't feel very strongly about this. The one use case I could imagine
> would be to do something for the GoogleTalk plugin.
> 
> But as I had noted in the commit message, it's unlikely that we would spend
the
> time actually doing anything.

I'm dropping it, we can revisit this if one day we're motivated to actually do
something with it.

[cevans, 2012-09-01 01:33:26]

On Fri, Aug 31, 2012 at 6:30 PM, <jln@chromium.org> wrote:

> On 2012/09/01 01:26:48, Julien Tinnes wrote:
>
>> On 2012/09/01 01:16:47, Jorge Lucangeli Obes wrote:
>> > On 2012/09/01 00:49:27, Julien Tinnes wrote:
>> > > On 2012/09/01 00:37:14, piman wrote:
>> > > > I'm confused - plugins can't be loaded in the sandbox.
>> > >
>> > > I saw that Windows supported trying to sandbox some plugins. I didn't
>> > > investigate this mechanism yet.
>> > >
>> > > I just wanted to make sure that InitializeSandbox() was called for
>> Linux
>>
> for
>
>> > > every process type.
>> > >
>> > > At the moment, for plugins, we don't do much (I applied the small
>>
> blacklist
>
>> > > policy that blacklists ptrace, maybe even that is too much and I
>> should
>>
> use
>
>> > > AllowAll ?).
>> >
>> > Chatted with Antoine about this. The plugin process loads NPAPI plugins
>>
> which
>
>> do
>> > not expect to be restricted in any way. If we want to have the plugin
>>
> process
>
>> go
>> > through InitializeSandbox for consistency, we should enable the AllowAll
>> policy.
>> >
>> > Even in that case, it's not crazy to think about the plugin process as
>> hopeless
>> > and special and keep it out of the InitializeSandbox path altogether.
>>
>
>  Yeah, I don't feel very strongly about this. The one use case I could
>> imagine
>> would be to do something for the GoogleTalk plugin.
>>
>
>  But as I had noted in the commit message, it's unlikely that we would
>> spend
>>
> the
>
>> time actually doing anything.
>>
>
> I'm dropping it, we can revisit this if one day we're motivated to
> actually do
> something with it.
>

Do we still have the --safe-plugins flag? In the early days of Windows,
this placed plug-ins inside the sandbox even though it broke them in
various ways. Interesting for testing.

If the flag still existed, it'd be interesting to give it a try on Linux.
For a start, it could imply the usual ptrace() restrictions plus deny of
opening any file for writing, plus deny of other filesystem-changing
syscalls (rename() unlink() etc).

I wouldn't be surprised if a reasonably safer Java couldn't be achieved
with a bit of fiddling.


>
https://chromiumcodereview.**appspot.com/10909044/<https://chromiumcodereview...
>

[jln (very slow on Chromium), 2012-09-01 01:58:45]

On Fri, Aug 31, 2012 at 6:33 PM, Chris Evans <cevans@google.com> wrote:

> Do we still have the --safe-plugins flag? In the early days of Windows, this
> placed plug-ins inside the sandbox even though it broke them in various
> ways. Interesting for testing.
>
> If the flag still existed, it'd be interesting to give it a try on Linux.
> For a start, it could imply the usual ptrace() restrictions plus deny of
> opening any file for writing, plus deny of other filesystem-changing
> syscalls (rename() unlink() etc).
>
> I wouldn't be surprised if a reasonably safer Java couldn't be achieved with
> a bit of fiddling.

There is still definitely some Windows sandbox initialization in
there. There is a special case for Flash, as we know.

Other than that, I've just noticed that ContentClient::SandboxPlugin()
actually just always returns false, so maybe I was mistaken before and
there  really nothing is done for plugins other than Flash.

Adding Justin to make sure I read that correctly. When did the
safe-plugins switch disappear ? I think I still have it in my windows
profile :)

Julien

[jschuh, 2012-09-01 02:01:52]

On Fri, Aug 31, 2012 at 6:58 PM, Julien Tinnes <jln@chromium.org> wrote:

> On Fri, Aug 31, 2012 at 6:33 PM, Chris Evans <cevans@google.com> wrote:
>
> > Do we still have the --safe-plugins flag? In the early days of Windows,
> this
> > placed plug-ins inside the sandbox even though it broke them in various
> > ways. Interesting for testing.
> >
> > If the flag still existed, it'd be interesting to give it a try on Linux.
> > For a start, it could imply the usual ptrace() restrictions plus deny of
> > opening any file for writing, plus deny of other filesystem-changing
> > syscalls (rename() unlink() etc).
> >
> > I wouldn't be surprised if a reasonably safer Java couldn't be achieved
> with
> > a bit of fiddling.
>
> There is still definitely some Windows sandbox initialization in
> there. There is a special case for Flash, as we know.
>
> Other than that, I've just noticed that ContentClient::SandboxPlugin()
> actually just always returns false, so maybe I was mistaken before and
> there  really nothing is done for plugins other than Flash.
>
> Adding Justin to make sure I read that correctly. When did the
> safe-plugins switch disappear ? I think I still have it in my windows
> profile :)
>

It's been gone for about a year because it was worthless (as in anything
you can do is trivially bypassed). I've spent too much time trying to
tackle that problem, and would advise anyone away from it. Best to just
leave NPAPI alone.

-j


Julien
>