Implement Connector::ApplySpec() & use to enforce navigation:frame

Implement Connector::ApplySpec() & use to enforce navigation:frame.

Rather than having InterfaceRegistry in the Service Manager client library implement capability enforcement in the client library (which forces us to shunt around capability info), we've been trying to have the Service Manager itself do enforcement. This is straightforward for connection-level requests, but for frame interfaces we would like to apply this enforcement on a defined scope as specified in the manifest, where the requestor-requestee relationship is direct currently and doesn't include the service manager.

Instead would like to route these requests through the service manager. This change adds a method to Connector() called ApplySpec which allows an InterfaceProviderSpec to be enforced on an InterfaceProvider&. The idea is:

1. some untrusted remote service calls in wanting an InterfaceProvider& to be bound.
2. target service wishes to have service manager control interface access on this IP& by some named spec. Forwards IP& to Service Manager and asks it to enforce named spec. As part of this it provides an IP back to itself that the Service Manager can forward allowed requests to.
3. SM performs filtering, forwarding permitted requests on to target service.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2816393002
Cr-Commit-Position: refs/heads/master@{#467415}
Committed: https://chromium.googlesource.com/chromium/src/+/b932d5ad0c349295c9d10de144f9358370e57b5c

[Ben Goodger (Google), 2017-04-17 04:50:07]

Description was changed from

==========
Straw man of Connector::ApplySpec().
==========

to

==========
Straw man of Connector::ApplySpec().
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[Ben Goodger (Google), 2017-04-17 05:33:15]

The CQ bit was checked by ben@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-17 05:33:52]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-17 06:34:37]

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

[commit-bot: I haz the power, 2017-04-17 06:34:38]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Ben Goodger (Google), 2017-04-17 14:58:24]

The CQ bit was checked by ben@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-17 14:58:32]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-17 15:35:31]

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

[commit-bot: I haz the power, 2017-04-17 15:35:32]

Dry run: Try jobs failed on following builders:
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ben Goodger (Google), 2017-04-17 17:43:33]

The CQ bit was checked by ben@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-17 17:43:57]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-17 18:38:51]

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

[commit-bot: I haz the power, 2017-04-17 18:38:52]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ben Goodger (Google), 2017-04-17 21:58:16]

The CQ bit was checked by ben@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-17 21:58:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-17 23:54:20]

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

[commit-bot: I haz the power, 2017-04-17 23:54:21]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ben Goodger (Google), 2017-04-25 01:10:47]

The CQ bit was checked by ben@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-25 01:11:24]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-25 02:32:45]

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

[commit-bot: I haz the power, 2017-04-25 02:32:46]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ben Goodger (Google), 2017-04-25 23:29:00]

The CQ bit was checked by ben@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-25 23:29:38]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ben Goodger (Google), 2017-04-25 23:32:35]

Description was changed from

==========
Straw man of Connector::ApplySpec().
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Implement Connector::ApplySpec() & use to enforce navigation:frame.

Rather than having InterfaceRegistry in the Service Manager client library
implement capability enforcement in the client library (which forces us to shunt
around capability info), we've been trying to have the Service Manager itself do
enforcement. This is straightforward for connection-level requests, but for
frame interfaces we would like to apply this enforcement on a defined scope as
specified in the manifest, where the requestor-requestee relationship is direct
currently and doesn't include the service manager.

Instead would like to route these requests through the service manager. This
change adds a method to Connector() called ApplySpec which allows an
InterfaceProviderSpec to be enforced on an InterfaceProvider&. The idea is:

1. some untrusted remote service calls in wanting an InterfaceProvider& to be
bound.
2. target service wishes to have service manager control interface access on
this IP& by some named spec. Forwards IP& to Service Manager and asks it to
enforce named spec. As part of this it provides an IP back to itself that the
Service Manager can forward allowed requests to.
3. SM performs filtering, forwarding permitted requests on to target service.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[Ben Goodger (Google), 2017-04-25 23:32:35]

ben@chromium.org changed reviewers:
+ rockot@chromium.org, tsepez@chromium.org

[Tom Sepez, 2017-04-25 23:51:20]

https://codereview.chromium.org/2816393002/diff/120001/services/service_manag...
File services/service_manager/public/interfaces/connector.mojom (right):

https://codereview.chromium.org/2816393002/diff/120001/services/service_manag...
services/service_manager/public/interfaces/connector.mojom:168: ApplySpec(string
spec,
I'm a little worried about parsing this (untrusted) spec in a more trusted
process.  Presently, these specs all come from manifests, and
the data is trusted.  But a renderer could pass up crafted input and force the
service manager to parse it?

[Ken Rockot(use gerrit already), 2017-04-26 00:06:34]

https://codereview.chromium.org/2816393002/diff/120001/services/service_manag...
File services/service_manager/public/interfaces/connector.mojom (right):

https://codereview.chromium.org/2816393002/diff/120001/services/service_manag...
services/service_manager/public/interfaces/connector.mojom:168: ApplySpec(string
spec,
On 2017/04/25 at 23:51:20, Tom Sepez wrote:
> I'm a little worried about parsing this (untrusted) spec in a more trusted
process.  Presently, these specs all come from manifests, and
> the data is trusted.  But a renderer could pass up crafted input and force the
service manager to parse it?

It's just the name of a spec. The spec itself is still looked up within the
manifest the service manager already has on hand for the service.

[commit-bot: I haz the power, 2017-04-26 00:38:26]

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

[commit-bot: I haz the power, 2017-04-26 00:38:27]

Dry run: This issue passed the CQ dry run.

[Ben Goodger (Google), 2017-04-26 02:26:40]

On 2017/04/26 00:06:34, Ken Rockot wrote:
>
https://codereview.chromium.org/2816393002/diff/120001/services/service_manag...
> File services/service_manager/public/interfaces/connector.mojom (right):
> 
>
https://codereview.chromium.org/2816393002/diff/120001/services/service_manag...
> services/service_manager/public/interfaces/connector.mojom:168:
ApplySpec(string
> spec,
> On 2017/04/25 at 23:51:20, Tom Sepez wrote:
> > I'm a little worried about parsing this (untrusted) spec in a more trusted
> process.  Presently, these specs all come from manifests, and
> > the data is trusted.  But a renderer could pass up crafted input and force
the
> service manager to parse it?
> 
> It's just the name of a spec. The spec itself is still looked up within the
> manifest the service manager already has on hand for the service.

Right. The string is just an identifier. It's a request to the service manager
to filter incoming interface requests to the spec with this name in the calling
service's manifest.

Possible conditions:

- The caller names the correct spec. The service manager forwards only requests
for interfaces associated with capabilities the holder of the remote end has
requested.
- The caller names some other spec from the caller's manifest (e.g.
"service_manager:connector" or some other one). Since the interfaces controlled
via that spec may not be exposed via the |target| parameter, this is unlikely to
work, but will not leak capabilities not already exposed.
- The caller names some non-existant spec. This will likely result in no
requests being forwarded at all, so results in no leakage of capabilities.

[Ben Goodger (Google), 2017-04-26 02:34:55]

The CQ bit was checked by ben@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-26 02:35:28]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ben Goodger (Google), 2017-04-26 02:36:05]

On 2017/04/26 02:26:40, Ben Goodger (Google) wrote:
> On 2017/04/26 00:06:34, Ken Rockot wrote:
> >
>
https://codereview.chromium.org/2816393002/diff/120001/services/service_manag...
> > File services/service_manager/public/interfaces/connector.mojom (right):
> > 
> >
>
https://codereview.chromium.org/2816393002/diff/120001/services/service_manag...
> > services/service_manager/public/interfaces/connector.mojom:168:
> ApplySpec(string
> > spec,
> > On 2017/04/25 at 23:51:20, Tom Sepez wrote:
> > > I'm a little worried about parsing this (untrusted) spec in a more trusted
> > process.  Presently, these specs all come from manifests, and
> > > the data is trusted.  But a renderer could pass up crafted input and force
> the
> > service manager to parse it?
> > 
> > It's just the name of a spec. The spec itself is still looked up within the
> > manifest the service manager already has on hand for the service.
> 
> Right. The string is just an identifier. It's a request to the service manager
> to filter incoming interface requests to the spec with this name in the
calling
> service's manifest.
> 
> Possible conditions:
> 
> - The caller names the correct spec. The service manager forwards only
requests
> for interfaces associated with capabilities the holder of the remote end has
> requested.
> - The caller names some other spec from the caller's manifest (e.g.
> "service_manager:connector" or some other one). Since the interfaces
controlled
> via that spec may not be exposed via the |target| parameter, this is unlikely
to
> work, but will not leak capabilities not already exposed.
> - The caller names some non-existant spec. This will likely result in no
> requests being forwarded at all, so results in no leakage of capabilities.

I updated this mojom with documentation which it looks like I forgot to write!

[Ben Goodger (Google), 2017-04-26 02:37:03]

The CQ bit was checked by ben@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-26 02:37:42]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-26 04:14:20]

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

[commit-bot: I haz the power, 2017-04-26 04:14:22]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Ken Rockot(use gerrit already), 2017-04-26 04:32:48]

https://codereview.chromium.org/2816393002/diff/160001/content/browser/frame_...
File content/browser/frame_host/render_frame_host_impl.cc (right):

https://codereview.chromium.org/2816393002/diff/160001/content/browser/frame_...
content/browser/frame_host/render_frame_host_impl.cc:3336:
BrowserContext::GetServiceUserIdFor(GetProcess()->GetBrowserContext()));
Weird - why wouldn't this already be set correctly in the return value of
GetChildIdentity()? Doesn't ChildConnection get setup with the right user ID?

https://codereview.chromium.org/2816393002/diff/160001/content/public/browser...
File content/public/browser/render_process_host.h (right):

https://codereview.chromium.org/2816393002/diff/160001/content/public/browser...
content/public/browser/render_process_host.h:286: virtual const
service_manager::Identity& GetChildIdentity() const = 0;
nit: GetRemoteIdentity() maybe?

https://codereview.chromium.org/2816393002/diff/160001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2816393002/diff/160001/content/renderer/rende...
content/renderer/render_frame_impl.cc:1319: void RenderFrameImpl::GetInterface(
nit: Should the position of this function definition match the order in the
header?

https://codereview.chromium.org/2816393002/diff/160001/services/service_manag...
File services/service_manager/public/interfaces/connector.mojom (right):

https://codereview.chromium.org/2816393002/diff/160001/services/service_manag...
services/service_manager/public/interfaces/connector.mojom:179: ApplySpec(string
spec,
I was kind of thinking we could call specs "interface filters" or "capability
filters". 

Related to but not dependent upon that thought, what about calling this
FilterInterfaces instead of ApplySpec? Then it's a little more clear from the
name what the purpose of the request is.

https://codereview.chromium.org/2816393002/diff/160001/services/service_manag...
File services/service_manager/service_manager.cc (right):

https://codereview.chromium.org/2816393002/diff/160001/services/service_manag...
services/service_manager/service_manager.cc:231: bool HasSpecNamed(const
std::string& spec) const {
nits: GetSpec and HasSpec? And vertical whitespace between methods.

https://codereview.chromium.org/2816393002/diff/160001/services/service_manag...
services/service_manager/service_manager.cc:319:
service_manager::ServiceManager* service_manager_;
nit: this could be const too (service_manager::ServiceManager* const
service_manager_)

https://codereview.chromium.org/2816393002/diff/160001/services/service_manag...
services/service_manager/service_manager.cc:398: mojo::MakeStrongBinding(
It's not safe to use StrongBinding here if you're going to hold a raw pointer to
ServiceManager. How about just having InterfaceProviderImpl own its own Binding,
and let Instance own all its active InterfaceProviderImpls?

[Tom Sepez, 2017-04-26 16:21:19]

Next question:  Until the ApplySpec() message arrives, do requests for the IP
all fail?

[Tom Sepez, 2017-04-26 16:22:36]

https://codereview.chromium.org/2816393002/diff/160001/services/service_manag...
File services/service_manager/public/interfaces/connector.mojom (right):

https://codereview.chromium.org/2816393002/diff/160001/services/service_manag...
services/service_manager/public/interfaces/connector.mojom:179: ApplySpec(string
spec,
On 2017/04/26 04:32:48, Ken Rockot wrote:
> I was kind of thinking we could call specs "interface filters" or "capability
> filters". 
> 
> Related to but not dependent upon that thought, what about calling this
> FilterInterfaces instead of ApplySpec? Then it's a little more clear from the
> name what the purpose of the request is.

Yea, SetInterfaceFilter(string filter_name, ... ???

[Ken Rockot(use gerrit already), 2017-04-26 16:25:47]

On 2017/04/26 at 16:21:19, tsepez wrote:
> Next question:  Until the ApplySpec() message arrives, do requests for the IP
all fail?

No, the pipe is unbound until the service manager receives ApplySpec and binds
it. Until it's bound its incoming messages are queued on the pipe.

[Ben Goodger (Google), 2017-04-26 17:00:07]

https://codereview.chromium.org/2816393002/diff/160001/content/browser/frame_...
File content/browser/frame_host/render_frame_host_impl.cc (right):

https://codereview.chromium.org/2816393002/diff/160001/content/browser/frame_...
content/browser/frame_host/render_frame_host_impl.cc:3336:
BrowserContext::GetServiceUserIdFor(GetProcess()->GetBrowserContext()));
On 2017/04/26 04:32:48, Ken Rockot wrote:
> Weird - why wouldn't this already be set correctly in the return value of
> GetChildIdentity()? Doesn't ChildConnection get setup with the right user ID?

No it uses kInheritUserID. Remember SM doesn't allow people to just provide a
user id. It likes to infer that. Maybe we could allow a carve-out for specifying
your own user id.

https://codereview.chromium.org/2816393002/diff/160001/content/public/browser...
File content/public/browser/render_process_host.h (right):

https://codereview.chromium.org/2816393002/diff/160001/content/public/browser...
content/public/browser/render_process_host.h:286: virtual const
service_manager::Identity& GetChildIdentity() const = 0;
On 2017/04/26 04:32:48, Ken Rockot wrote:
> nit: GetRemoteIdentity() maybe?

Isn't child more accurate? This is the host of a specific child process.

https://codereview.chromium.org/2816393002/diff/160001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2816393002/diff/160001/content/renderer/rende...
content/renderer/render_frame_impl.cc:1319: void RenderFrameImpl::GetInterface(
On 2017/04/26 04:32:48, Ken Rockot wrote:
> nit: Should the position of this function definition match the order in the
> header?

Yes. This file is a shit-show.

https://codereview.chromium.org/2816393002/diff/160001/services/service_manag...
File services/service_manager/public/interfaces/connector.mojom (right):

https://codereview.chromium.org/2816393002/diff/160001/services/service_manag...
services/service_manager/public/interfaces/connector.mojom:179: ApplySpec(string
spec,
On 2017/04/26 04:32:48, Ken Rockot wrote:
> I was kind of thinking we could call specs "interface filters" or "capability
> filters". 
> 
> Related to but not dependent upon that thought, what about calling this
> FilterInterfaces instead of ApplySpec? Then it's a little more clear from the
> name what the purpose of the request is.

FilterInterfaces sounds fine.

[Ben Goodger (Google), 2017-04-26 17:26:59]

Updated per other comments.

https://codereview.chromium.org/2816393002/diff/160001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2816393002/diff/160001/content/renderer/rende...
content/renderer/render_frame_impl.cc:1319: void RenderFrameImpl::GetInterface(
On 2017/04/26 17:00:07, Ben Goodger (Google) wrote:
> On 2017/04/26 04:32:48, Ken Rockot wrote:
> > nit: Should the position of this function definition match the order in the
> > header?
> 
> Yes. This file is a shit-show.

Actually it does match the function definition order in the header. :p

[Ben Goodger (Google), 2017-04-26 17:27:14]

The CQ bit was checked by ben@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-26 17:27:51]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Tom Sepez, 2017-04-26 17:39:08]

lgtm

[Ken Rockot(use gerrit already), 2017-04-26 17:39:19]

lgtm

https://codereview.chromium.org/2816393002/diff/160001/content/browser/frame_...
File content/browser/frame_host/render_frame_host_impl.cc (right):

https://codereview.chromium.org/2816393002/diff/160001/content/browser/frame_...
content/browser/frame_host/render_frame_host_impl.cc:3336:
BrowserContext::GetServiceUserIdFor(GetProcess()->GetBrowserContext()));
On 2017/04/26 at 17:00:07, Ben Goodger (Google) wrote:
> On 2017/04/26 04:32:48, Ken Rockot wrote:
> > Weird - why wouldn't this already be set correctly in the return value of
> > GetChildIdentity()? Doesn't ChildConnection get setup with the right user
ID?
> 
> No it uses kInheritUserID. Remember SM doesn't allow people to just provide a
user id. It likes to infer that. Maybe we could allow a carve-out for specifying
your own user id.

Oh right. It's the BrowserContext's content_browser connection that has the
right user ID, and that uses StartService with kInheritUserId. Bummer.

Thinking about this some more I kind of wonder if this shouldn't just be service
name instead of Identity. Why does the Service Manager need to look up a
specific Instance in order to retrieve the relevant spec information?

Anyway, if that's too much of a PITA or you think it's otherwise worth leaving
as Identity, I'm OK with leaving this as-is.

[commit-bot: I haz the power, 2017-04-26 18:33:40]

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

[commit-bot: I haz the power, 2017-04-26 18:33:41]

Dry run: This issue passed the CQ dry run.

[Ben Goodger (Google), 2017-04-26 19:25:55]

The CQ bit was checked by ben@chromium.org

[commit-bot: I haz the power, 2017-04-26 19:26:59]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-26 19:40:16]

CQ is committing da patch.

Bot data: {"patchset_id": 180001, "attempt_start_ts": 1493234755416510,
"parent_rev": "47e29208adba250e05e256ed3e21b6c84ca7ef22", "commit_rev":
"b932d5ad0c349295c9d10de144f9358370e57b5c"}

[commit-bot: I haz the power, 2017-04-26 19:40:36]

Description was changed from

==========
Implement Connector::ApplySpec() & use to enforce navigation:frame.

Rather than having InterfaceRegistry in the Service Manager client library
implement capability enforcement in the client library (which forces us to shunt
around capability info), we've been trying to have the Service Manager itself do
enforcement. This is straightforward for connection-level requests, but for
frame interfaces we would like to apply this enforcement on a defined scope as
specified in the manifest, where the requestor-requestee relationship is direct
currently and doesn't include the service manager.

Instead would like to route these requests through the service manager. This
change adds a method to Connector() called ApplySpec which allows an
InterfaceProviderSpec to be enforced on an InterfaceProvider&. The idea is:

1. some untrusted remote service calls in wanting an InterfaceProvider& to be
bound.
2. target service wishes to have service manager control interface access on
this IP& by some named spec. Forwards IP& to Service Manager and asks it to
enforce named spec. As part of this it provides an IP back to itself that the
Service Manager can forward allowed requests to.
3. SM performs filtering, forwarding permitted requests on to target service.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Implement Connector::ApplySpec() & use to enforce navigation:frame.

Rather than having InterfaceRegistry in the Service Manager client library
implement capability enforcement in the client library (which forces us to shunt
around capability info), we've been trying to have the Service Manager itself do
enforcement. This is straightforward for connection-level requests, but for
frame interfaces we would like to apply this enforcement on a defined scope as
specified in the manifest, where the requestor-requestee relationship is direct
currently and doesn't include the service manager.

Instead would like to route these requests through the service manager. This
change adds a method to Connector() called ApplySpec which allows an
InterfaceProviderSpec to be enforced on an InterfaceProvider&. The idea is:

1. some untrusted remote service calls in wanting an InterfaceProvider& to be
bound.
2. target service wishes to have service manager control interface access on
this IP& by some named spec. Forwards IP& to Service Manager and asks it to
enforce named spec. As part of this it provides an IP back to itself that the
Service Manager can forward allowed requests to.
3. SM performs filtering, forwarding permitted requests on to target service.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2816393002
Cr-Commit-Position: refs/heads/master@{#467415}
Committed:
https://chromium.googlesource.com/chromium/src/+/b932d5ad0c349295c9d10de144f9...
==========

[commit-bot: I haz the power, 2017-04-26 19:40:37]

Committed patchset #10 (id:180001) as
https://chromium.googlesource.com/chromium/src/+/b932d5ad0c349295c9d10de144f9...