NaCl: Supply Windows handle-passing function

Supply Windows handle-passing function to NaCl

Pass BrokerDuplicateHandle() to the NaCl loader process in
nacl_listener.cc.

Pass BrokerDuplicateHandle() to the NaCl trusted plugin.  We need to
add this to PPB_NaCl_Private in order to pass it through.

Remove the use of the "init_handle_passing" SRPC call.  Otherwise the
NaCl process will attempt to do an imc_connect() to the renderer,
which involves sending a handle to it, which fails.

Add a wrapper for AddTargetPeer() to 'content' so that
nacl_process_host.cc can use it.

Change the renderer's handle-passing policy to allow sending handles
other than Sections.  The NaCl trusted plugin sends other handle types
to the NaCl loader process.

This change will allow the sandbox to be tightened up, in the future,
so that the NaCl loader process and the renderer process do not have
handles to each other.

BUG=http://code.google.com/p/nativeclient/issues/detail?id=2719
TEST=nacl_integration etc.

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

[Mark Seaborn, 2012-04-10 17:47:17]

@Justin: This change is not committable yet (it depends on
http://codereview.chromium.org/9960060/) and I am not asking you to review it
yet.

This is to let you know that I found two problems when I tried using
BrokerDuplicateHandle() for NaCl:

 * I needed to allow duplicating handle types other than "Section".

 * The process ID check fails when the 32-bit renderer process tries to send a
handle to the 64-bit NaCl process.  That is presumably because 32-bit processes
have a different sandbox broker process from 64-bit processes, and the two
brokers don't know about each others' processes.

Mark

[Mark Seaborn, 2012-04-12 17:40:52]

This should be ready to go now that http://codereview.chromium.org/9960045/ is
committed.  Please take a look.

+dmichael for ppapi/c/private/ppb_nacl_private.h
+sehr for all but content/*

[dmichael (off chromium), 2012-04-12 18:44:48]

ppapi/* lgtm

[jschuh, 2012-04-12 22:42:03]

http://codereview.chromium.org/10039001/diff/12001/content/common/sandbox_pol...
File content/common/sandbox_policy.cc (right):

http://codereview.chromium.org/10039001/diff/12001/content/common/sandbox_pol...
content/common/sandbox_policy.cc:386: L"*");
Does this really need to be "*"?

[Mark Seaborn, 2012-04-13 00:50:28]

http://codereview.chromium.org/10039001/diff/12001/content/common/sandbox_pol...
File content/common/sandbox_policy.cc (right):

http://codereview.chromium.org/10039001/diff/12001/content/common/sandbox_pol...
content/common/sandbox_policy.cc:386: L"*");
On 2012/04/12 22:42:03, Justin Schuh wrote:
> Does this really need to be "*"?

OK, I wasn't sure if listing handle types bought us much, but I suppose it's
worth it as a sanity check.  It turns out all of NaCl's handle use should be
covered by whitelisting the File type (for named pipe handles and shared
memory).  Changed.

[jschuh, 2012-04-13 00:58:46]

On 2012/04/13 00:50:28, Mark Seaborn wrote:
>
http://codereview.chromium.org/10039001/diff/12001/content/common/sandbox_pol...
> File content/common/sandbox_policy.cc (right):
> 
>
http://codereview.chromium.org/10039001/diff/12001/content/common/sandbox_pol...
> content/common/sandbox_policy.cc:386: L"*");
> On 2012/04/12 22:42:03, Justin Schuh wrote:
> > Does this really need to be "*"?
> 
> OK, I wasn't sure if listing handle types bought us much, but I suppose it's
> worth it as a sanity check.  It turns out all of NaCl's handle use should be
> covered by whitelisting the File type (for named pipe handles and shared
> memory).  Changed.

Thanks. In this case it is less about blocking for security than it is about
having accurate knowledge of what we're choosing to expose.

lgtm btw

[sehr (please use chromium), 2012-04-13 19:54:02]

On 2012/04/13 00:58:46, Justin Schuh wrote:
> On 2012/04/13 00:50:28, Mark Seaborn wrote:
> >
>
http://codereview.chromium.org/10039001/diff/12001/content/common/sandbox_pol...
> > File content/common/sandbox_policy.cc (right):
> > 
> >
>
http://codereview.chromium.org/10039001/diff/12001/content/common/sandbox_pol...
> > content/common/sandbox_policy.cc:386: L"*");
> > On 2012/04/12 22:42:03, Justin Schuh wrote:
> > > Does this really need to be "*"?
> > 
> > OK, I wasn't sure if listing handle types bought us much, but I suppose it's
> > worth it as a sanity check.  It turns out all of NaCl's handle use should be
> > covered by whitelisting the File type (for named pipe handles and shared
> > memory).  Changed.
> 
> Thanks. In this case it is less about blocking for security than it is about
> having accurate knowledge of what we're choosing to expose.
> 
> lgtm btw

LGTM.

[Mark Seaborn, 2012-04-16 17:47:18]

I've rebased this now.

@jam: Please review the content/public change.

[jam, 2012-04-16 23:46:23]

lgtm