Bind before sandbox lockdown on Windows.

Bind before sandbox lockdown on Windows.
Linux is unaffected. All changed code already is inside sandbox.

BUG=348692
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255311

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255900

[jschuh, 2014-03-05 00:58:21]

Meh. I'd rather not have buggy LSPs in our process at all, but under the
circumstances this is reasonable. lgtm

[Vitaly Buka (NO REVIEWS), 2014-03-05 01:58:26]

The CQ bit was checked by vitalybuka@chromium.org

[commit-bot: I haz the power, 2014-03-05 02:05:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vitalybuka@chromium.org/185293014/40001

[Vitaly Buka (NO REVIEWS), 2014-03-05 02:08:17]

The CQ bit was unchecked by vitalybuka@chromium.org

[Vitaly Buka (NO REVIEWS), 2014-03-05 02:27:23]

+sergeyu for content/browser/renderer_host/p2p

[rvargas (doing something else), 2014-03-05 02:54:26]

The CL itself looks fine to me. I still have concerns about the whole
pre-warming the network for a renderer, but that is not really directly related
to this CL.

Is there a bug/design doc that you could point me to?

lgtm

https://codereview.chromium.org/185293014/diff/60001/net/udp/datagram_server_...
File net/udp/datagram_server_socket.h (right):

https://codereview.chromium.org/185293014/diff/60001/net/udp/datagram_server_...
net/udp/datagram_server_socket.h:107: // Detach from thread used to check for
thread-safety.
nit: How about "Resets the thread to be used for thread-safety checks" (and
elsewhere)

[cpu_(ooo_6.6-7.5), 2014-03-05 03:03:07]

Justin,

Can you come by and explain what these folks are doing?

Please belay the commit for a day or so. Thanks for your patience. Your CL is
important to us.

[Vitaly Buka (NO REVIEWS), 2014-03-05 03:11:03]

On Tue, Mar 4, 2014 at 7:05 PM, Justin Schuh <jschuh@chromium.org> wrote:

> It's not a renderer. It's the mdns resolver process.
> On Mar 4, 2014 7:03 PM, <cpu@chromium.org> wrote:
>
>> Justin,
>>
>> Can you come by and explain what these folks are doing?
>>
>> Please belay the commit for a day or so. Thanks for your patience. Your
>> CL is
>> important to us.
>>
>>
>> https://codereview.chromium.org/185293014/
>
>

On Tue, Mar 4, 2014 at 7:03 PM, <cpu@chromium.org> wrote:

> Justin,
>
> Can you come by and explain what these folks are doing?
>
> Please belay the commit for a day or so. Thanks for your patience. Your CL
> is
> important to us.
>
>
> https://codereview.chromium.org/185293014/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jschuh, 2014-03-05 04:02:11]

That's what I get for responding from a phone. So, the deal is that this process
runs only the mdns resolver, and nothing else. It's not a renderer process, and
will not open any new attack surface to renderers or other sandboxed processes.
Basically, this is the first attempt at making a sandboxed network component.

[rvargas (doing something else), 2014-03-05 04:19:45]

On 2014/03/05 04:02:11, Justin Schuh wrote:
> Basically, this is the first attempt at making a sandboxed network component.

I know you've used that characterization today, but I seriously disagree with it
:)

[jschuh, 2014-03-05 04:48:24]

On 2014/03/05 04:19:45, rvargas wrote:
> On 2014/03/05 04:02:11, Justin Schuh wrote:
> > Basically, this is the first attempt at making a sandboxed network
component.
> 
> I know you've used that characterization today, but I seriously disagree with
it
> :)

This was the first time actually, but now I'm very curious what you mean. :)

[Sergey Ulanov, 2014-03-05 18:55:30]

content/browser/renderer_host/p2p - LGTM

[Vitaly Buka (NO REVIEWS), 2014-03-05 19:07:11]

https://codereview.chromium.org/185293014/diff/60001/net/udp/datagram_server_...
File net/udp/datagram_server_socket.h (right):

https://codereview.chromium.org/185293014/diff/60001/net/udp/datagram_server_...
net/udp/datagram_server_socket.h:107: // Detach from thread used to check for
thread-safety.
On 2014/03/05 02:54:26, rvargas wrote:
> nit: How about "Resets the thread to be used for thread-safety checks" (and
> elsewhere)

Done.

[rvargas (doing something else), 2014-03-05 20:23:34]

On 2014/03/05 04:48:24, Justin Schuh wrote:
> On 2014/03/05 04:19:45, rvargas wrote:
> > On 2014/03/05 04:02:11, Justin Schuh wrote:
> > > Basically, this is the first attempt at making a sandboxed network
> component.
> > 
> > I know you've used that characterization today, but I seriously disagree
with
> it
> > :)
> 
> This was the first time actually, but now I'm very curious what you mean. :)

You implied that a few times on the email thread.

I think this _could_ be considered an experiment into _one_ of the issues of
having a dedicated network process, but I don't considered it to be connected in
any way with any real plan of building a network process.

In fact, from the discussions about a network process, it was clear that LSPs
would have serious issues if we attempted to run them inside a sandbox, and also
that we could not brake them or pretend that they will go away from what is the
OS standard programming model (aka, LSPs).

What would be the best way of applying some sort of sandbox to a network process
has only been the realm of vague ideas and speculation (I may be mistaken, of
course, but I don't think we have a well thought out strategy). As far as I'm
concerned, once we allow large swats of untrusted code (aka, LSPs) to run before
lockdown, it's pretty much game over.

[jschuh, 2014-03-05 20:57:04]

On 2014/03/05 20:23:34, rvargas wrote:
> On 2014/03/05 04:48:24, Justin Schuh wrote:
> > On 2014/03/05 04:19:45, rvargas wrote:
> > > On 2014/03/05 04:02:11, Justin Schuh wrote:
> > > > Basically, this is the first attempt at making a sandboxed network
> > component.
> > > 
> > > I know you've used that characterization today, but I seriously disagree
> with
> > it
> > > :)
> > 
> > This was the first time actually, but now I'm very curious what you mean. :)
> 
> You implied that a few times on the email thread.

Nope. I noted that these are the same issues that were raised during past
discussions about sandboxing the network process, which is why I looped in the
network team. Until a few days ago, I was under the impression that the work on
mDNS etc. was being coordinated with the network team.


> I think this _could_ be considered an experiment into _one_ of the issues of
> having a dedicated network process, but I don't considered it to be connected
in
> any way with any real plan of building a network process.
> 
> In fact, from the discussions about a network process, it was clear that LSPs
> would have serious issues if we attempted to run them inside a sandbox, and
also
> that we could not brake them or pretend that they will go away from what is
the
> OS standard programming model (aka, LSPs).
> 
> What would be the best way of applying some sort of sandbox to a network
process
> has only been the realm of vague ideas and speculation (I may be mistaken, of
> course, but I don't think we have a well thought out strategy). As far as I'm
> concerned, once we allow large swats of untrusted code (aka, LSPs) to run
before
> lockdown, it's pretty much game over.

[cpu_(ooo_6.6-7.5), 2014-03-05 22:45:37]

As per email conversation lgtm . Lets work on the transition plan to something
better for m35/m36.

[Vitaly Buka (NO REVIEWS), 2014-03-05 23:18:36]

The CQ bit was checked by vitalybuka@chromium.org

[commit-bot: I haz the power, 2014-03-05 23:18:44]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vitalybuka@chromium.org/185293014/100001

[commit-bot: I haz the power, 2014-03-06 00:09:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vitalybuka@chromium.org/185293014/100001

[commit-bot: I haz the power, 2014-03-06 00:51:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-06 00:51:47]

Retried try job too often on win_rel for step(s) app_list_unittests,
ash_unittests, aura_unittests, base_unittests, browser_tests,
cacheinvalidation_unittests, cc_unittests, check_deps, check_deps2git,
chrome_elf_unittests, chromedriver_unittests, components_unittests,
compositor_unittests, content_browsertests, content_unittests, crypto_unittests,
events_unittests, gfx_unittests, google_apis_unittests, gpu_unittests,
installer_util_unittests, interactive_ui_tests, ipc_tests, jingle_unittests,
media_unittests, mini_installer_test, nacl_integration, net_unittests,
ppapi_unittests, printing_unittests, remoting_unittests, sql_unittests,
sync_integration_tests, sync_unit_tests, telemetry_perf_unittests,
telemetry_unittests, unit_tests, views_unittests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[Vitaly Buka (NO REVIEWS), 2014-03-06 00:52:48]

The CQ bit was checked by vitalybuka@chromium.org

[commit-bot: I haz the power, 2014-03-06 00:55:28]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vitalybuka@chromium.org/185293014/100001

[commit-bot: I haz the power, 2014-03-06 02:53:05]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vitalybuka@chromium.org/185293014/100001

[commit-bot: I haz the power, 2014-03-06 03:17:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vitalybuka@chromium.org/185293014/100001

[commit-bot: I haz the power, 2014-03-06 11:02:38]

Change committed as 255311

[Vitaly Buka (NO REVIEWS), 2014-03-09 08:53:35]

The CQ bit was checked by vitalybuka@chromium.org

[commit-bot: I haz the power, 2014-03-09 08:53:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vitalybuka@chromium.org/185293014/160001

[commit-bot: I haz the power, 2014-03-09 11:12:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-09 11:12:05]

Retried try job too often on win_rel for step(s) unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[Vitaly Buka (NO REVIEWS), 2014-03-09 22:47:07]

The CQ bit was checked by vitalybuka@chromium.org

[commit-bot: I haz the power, 2014-03-09 22:47:19]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vitalybuka@chromium.org/185293014/160001

[commit-bot: I haz the power, 2014-03-10 07:18:39]

Change committed as 255900