This CL is a first step towards implementing origin isolation opt-in
via OriginPolicy.
At present, this CL just looks for the existence of any top-level
"isolation" key (true or a dict) in the OriginPolicy manifest.
The opt-in status is stored in ChildProcessSecurityPolicyImpl in two
ways:
* a master opt-in list that reflects the opt-in status for a given
origin as of the most recently received OriginPolicy, and
* a per-BrowsingInstance map that tracks all origins that have been
loaded into that BrowsingInstance and have isolation enabled.
The first navigation to an origin in a BrowsingInstance will respect the
current opt-in status in the master opt-in list, and if the origin opts
in to isolation the opt-in status with respect to the BrowsingInstance
is set at that time. However, if an origin does not opt in, then this
CL does not track that (this will be in a near-future CL).
This CL should be a functional implementation of origin-isolation opt-in
and only requires --enable-features=OriginPolicy to enable it. Of
course, one also needs an origin's server to send an appropriate
OriginPolicy manifest.
Bug: 1042415
Change-Id: I1d7ecb4c77a52048bd2ebe780d763e47270ea5e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1956014
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735125}
Other enterprise features use the [*.] syntax to specify wildcard
matching, modify the wildcard isolated origins code to use this syntax
for consistency.
Bug=chromium:926997
Change-Id: Ib753aa626a8020b6391db6e9a500690cfa8d80e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1688539
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Andrew Stone <ajws@google.com>
Cr-Commit-Position: refs/heads/master@{#675932}
1. Add a string variant of AddIsolatedOrigins().
Command line, enterprise policy and field trial code presents isolated
origins as a single comma separated string.
ChildProcessSecurityPolicy can now parse these strings directly,
avoiding the need to make the internal implementation of wildcard
patterns visible to /src/content/public.
This change enables wildcard domains (domains of the form
"http(s)://**.foo.bar.com") to be specified alongside non-wildcard
domains on the command line, as part of a field trial or via
enterprise policy.
For example, start Chrome with the command line switch
"--isolate-origins=https://**.foo.bar.com,https://baz.com" to ensure
that baz.com is an isolated origin, and any origin under foo.bar.com
will be treated as an isolated origin, i.e. https://a.foo.bar.com and
https://b.foo.bar.com will be treated as separate origins.
2. Add BrowserTests for wildcard origins.
Show that navigations between hosts within wildcard isolated
sub-domains always receive new processes, while not affecting process
reuse of navigations within a non-wildcard domain.
3. Fix operator== of IsolatedOriginPattern.
|pattern_| was erroneously included in operator==(), which meant that
equivalent domains with different patterns would fail equality checks,
e.g "https://foo.com/" and "https://foo.com" would not be considered
equal because of the trailing slash, yet they are equivalent when used
as url::Origins. Unit tests for this behaviour are added as part of
ChildProcessSecurityPolicyTest.
Bug=chromium:926997
Change-Id: I4fcad7fd8cc641cfacd94903466ff4e46317b616
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1666371
Commit-Queue: Andrew Stone <ajws@google.com>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#672429}
1. Make GetMatchingIsolatedOrigin() respect wildcard isolated origins.
The matching behaviour for GetMatchingIsolatedOrigin() is changed such
that when iterating the list of isolated origins per site, if a
wildcard origin is encountered, the function returns immediately. This
prevents a non-wildcard isolated origin elsewhere in the set being
matched.
2. Add isolating wildcard domains to ChildProcessSecurityPolicy.
Provide an additional implementation of AddIsolatedOrigins which
accepts a list of IsolatedOriginPatterns, correctly preseving whether
or not they are wildcard isolated origins when converted to
IsolatedOriginEntries.
3. Add IsolatedOriginPattern, a container class for wildcard patterns.
In order to add support for isolating all sub-domains of an origin,
expressed by a double asterisk (e.g. https://**.foo.com) a new
container class is required. We are unable to use GURL or url::Origin
to hold these patterns as they escape the '*' character to '%2A', which
would make parsing brittle if this behaviour ever changes in the
future.
Instead we propose to hold user-supplied data in an
IsolatedOriginPattern instance, which correctly identifies and removes
wildcards. After removal of the wildcards conversion to url::Origin()
is possible, requiring only minimal changes to code that calls
ChildProcesssecurityPolicyImpl::AddIsolatedOrigins().
4. Add double-wildcard support to IsolatedOriginEntries.
Double wildcard origins are origins for which any sub-domain should be
subject to site isolation. By default the varaiable is initialised to
false; future commits will permit callers of
ChildProcessSecurityPolicy::AddIsolatedOrigins() to specify URLs of
the form https://**.foo.com to isolate any sub-domain that matches the
specified pattern.
Design doc for these chanes is available here:
http://doc/1nAL_ZH64weVOaTSpfA85MOdNW1RzTAZg2A3i1oixAuE
Bug=chromium:926997
Change-Id: I5259cf1e7fd69ad933ce741debb979c155d0a9bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1589080
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Andrew Stone <ajws@google.com>
Cr-Commit-Position: refs/heads/master@{#667030}
Previously, if bar.foo.com was an isolated origin, subdomains like
subdomain.bar.foo.com would end up in a different SiteInstance (using
"foo.com" for its site URL) than the isolated origin, which was
confusing/undesirable. There was also confusion with subdomains if an
etld+1 (e.g., isolated.com) was marked as an isolated origin: we would
try to assign a different SiteInstance to foo.isolated.com than
isolated.com, yet the site URL would still resolve to "isolated.com".
This CL changes this behavior to keep subdomains in the isolated
origin's SiteInstance. It also adds conflict resolution, which allows
adding multiple isolated origins with a common domain (e.g., c.b.a.com
and a.com), where the most specific isolated origin is used when
picking the SiteInstance site URL for a particular URL (e.g., b.a.com
would use a.com, but d.c.b.a.com would use c.b.a.com).
For more discussion about this, see the isolated origin design doc:
https://goo.gl/99ynqK
BUG=713444
Review-Url: https://codereview.chromium.org/2891443002
Cr-Commit-Position: refs/heads/master@{#483881}
