This CL adds a service process host option to pin user32
prior to lockdown in utility main, and plumbs the option
from the service process host.
Echo service tests are added to exercise the function
in user32 which motivated user32 pinning for services.
As content_browsertests effectively pins user32 anyway
this test always passes, but it will prevent regressions.
Services will migrate to use this API in a following CL.
Bug: 1435571,1408988
Change-Id: Ie36f16987f05cdcf42c70d28afbb04f6678c1e5e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4534183
Reviewed-by: Ken Rockot <rockot@google.com>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1146962}
This is a reland of commit fe96e5d8bd
Now builds correctly for asan.
Additionally, during testing a flaky failure was uncovered where
the mojo service could start before the preloading happened, this
is resolved by moving the preloading code ahead of IO thread
creation in UtilityMain.
Original change's description:
> Allow utilities to preload libraries before sandbox lockdown
>
> Some utilities on Windows wrap dynamic libraries which might be
> distributed as components. Allowing these to load requires punching
> holes in the sandbox using file interceptions that are being phased
> out.
>
> This CL introduces a mechanism for service processes to specify a
> list of dll paths which will be loaded before the sandbox goes into
> lockdown. They can later be loaded by code using the same path, as
> Windows keeps them in memory.
>
> The mechanism uses a new opaque data transfer mechanism in the
> sandbox which will extend to different uses later. For
> now the list of DLLs is the only data transferred so this CL uses
> base::Pickle to serialize & transfer the DLLs to load.
>
> As loading arbitrary DLLs is a powerful capability a passkey is
> added for the new service process host option, and a file containing
> valid callers is added with OWNERS from the sandbox to ensure
> security review.
>
> A following CL will enable this behavior for screen_ai, but at this
> point only tests exercise these APIs
>
> The flow is roughly:
> ---
> In the browser/broker:-
>
> ServiceProcessHost gets a new option:
> .WithPreloadedLibraries
>
> UtilityProcessHost gets a new member:
> preload_libraries_
>
> UtilityProcessHost gives this to the UtilitySandboxedProcessLauncherDelegate
>
> UtilitySandboxedProcessLauncherDelegate turns a list of DLLs into an
> opaque blob and attaches it to the sandbox's TargetPolicy during
> PreSpawnTarget.
>
> The sandbox smuggles this blob into the target (previous CL).
>
> In the child/target:-
>
> The UtilityMain knows it might have a blob, so asks TargetServices.
>
> UtilityMain coordinates with its sandbox delegate, so knows that
> the blob is a pickled list of DLLs.
>
> UtilityMain loads these dlls before sandbox lockdown.
> ---
>
> Bug: 1435571
> Change-Id: Ided63f9d723811b66c183335b5533c84e9783a2a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4471953
> Reviewed-by: Nasko Oskov <nasko@chromium.org>
> Reviewed-by: Ken Rockot <rockot@google.com>
> Reviewed-by: Will Harris <wfh@chromium.org>
> Commit-Queue: Will Harris <wfh@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1137415}
Bug: 1435571
Change-Id: Id0156d4649efd67adc5fe2eadaa73415b9c35503
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4518747
Reviewed-by: Ken Rockot <rockot@google.com>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1143553}
This reverts commit fe96e5d8bd.
Reason for revert: This appears to be the cause of a build failure on win-asan that is closing the tree:
ci.chromium.org/ui/p/chromium/builders/ci/win-asan/26430/overview
Original change's description:
> Allow utilities to preload libraries before sandbox lockdown
>
> Some utilities on Windows wrap dynamic libraries which might be
> distributed as components. Allowing these to load requires punching
> holes in the sandbox using file interceptions that are being phased
> out.
>
> This CL introduces a mechanism for service processes to specify a
> list of dll paths which will be loaded before the sandbox goes into
> lockdown. They can later be loaded by code using the same path, as
> Windows keeps them in memory.
>
> The mechanism uses a new opaque data transfer mechanism in the
> sandbox which will extend to different uses later. For
> now the list of DLLs is the only data transferred so this CL uses
> base::Pickle to serialize & transfer the DLLs to load.
>
> As loading arbitrary DLLs is a powerful capability a passkey is
> added for the new service process host option, and a file containing
> valid callers is added with OWNERS from the sandbox to ensure
> security review.
>
> A following CL will enable this behavior for screen_ai, but at this
> point only tests exercise these APIs
>
> The flow is roughly:
> ---
> In the browser/broker:-
>
> ServiceProcessHost gets a new option:
> .WithPreloadedLibraries
>
> UtilityProcessHost gets a new member:
> preload_libraries_
>
> UtilityProcessHost gives this to the UtilitySandboxedProcessLauncherDelegate
>
> UtilitySandboxedProcessLauncherDelegate turns a list of DLLs into an
> opaque blob and attaches it to the sandbox's TargetPolicy during
> PreSpawnTarget.
>
> The sandbox smuggles this blob into the target (previous CL).
>
> In the child/target:-
>
> The UtilityMain knows it might have a blob, so asks TargetServices.
>
> UtilityMain coordinates with its sandbox delegate, so knows that
> the blob is a pickled list of DLLs.
>
> UtilityMain loads these dlls before sandbox lockdown.
> ---
>
> Bug: 1435571
> Change-Id: Ided63f9d723811b66c183335b5533c84e9783a2a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4471953
> Reviewed-by: Nasko Oskov <nasko@chromium.org>
> Reviewed-by: Ken Rockot <rockot@google.com>
> Reviewed-by: Will Harris <wfh@chromium.org>
> Commit-Queue: Will Harris <wfh@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1137415}
Bug: 1435571
Change-Id: I8b3fd2ae342a173c532da08f1015266cf5d7b64c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4492274
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Michael Wilson <mjwilson@chromium.org>
Commit-Queue: Michael Wilson <mjwilson@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1137435}
Some utilities on Windows wrap dynamic libraries which might be
distributed as components. Allowing these to load requires punching
holes in the sandbox using file interceptions that are being phased
out.
This CL introduces a mechanism for service processes to specify a
list of dll paths which will be loaded before the sandbox goes into
lockdown. They can later be loaded by code using the same path, as
Windows keeps them in memory.
The mechanism uses a new opaque data transfer mechanism in the
sandbox which will extend to different uses later. For
now the list of DLLs is the only data transferred so this CL uses
base::Pickle to serialize & transfer the DLLs to load.
As loading arbitrary DLLs is a powerful capability a passkey is
added for the new service process host option, and a file containing
valid callers is added with OWNERS from the sandbox to ensure
security review.
A following CL will enable this behavior for screen_ai, but at this
point only tests exercise these APIs
The flow is roughly:
---
In the browser/broker:-
ServiceProcessHost gets a new option:
.WithPreloadedLibraries
UtilityProcessHost gets a new member:
preload_libraries_
UtilityProcessHost gives this to the UtilitySandboxedProcessLauncherDelegate
UtilitySandboxedProcessLauncherDelegate turns a list of DLLs into an
opaque blob and attaches it to the sandbox's TargetPolicy during
PreSpawnTarget.
The sandbox smuggles this blob into the target (previous CL).
In the child/target:-
The UtilityMain knows it might have a blob, so asks TargetServices.
UtilityMain coordinates with its sandbox delegate, so knows that
the blob is a pickled list of DLLs.
UtilityMain loads these dlls before sandbox lockdown.
---
Bug: 1435571
Change-Id: Ided63f9d723811b66c183335b5533c84e9783a2a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4471953
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Will Harris <wfh@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1137415}
Before this CL access to system fonts was determined based
on process or sandbox type in sandbox::policy::win. After
this CL this decision is made by the delegates attached to
the relevant process hosts.
To support this in the renderer sandbox delegate we need to
know if a renderer is a pdf renderer or a normal web renderer,
so we add a member to the delegate to report this and plumb
that info through the delegate. This changes the tags that
the delegate should report - previously PDF renderer sandboxes
were identical to jitless renderer sandboxes but now they are
different, so we add a new tag that can be reported.
The feature WinSboxAllowSystemFonts now only toggles direct
font access for web renderers, all other process that might
need this rule always get it and are not controlled by the
feature. The feature remains default 'on' so that all
existing processes that access system fonts directly still
do.
Bug: 1023583,1425413
Change-Id: I07633e0a5a4ca626326b4cb77f880ae54e31bd70
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4354680
Reviewed-by: Will Harris <wfh@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1120587}
This CL adds the new InitializeConfig method to SandboxDelegate to
clearly separate out code to setup the fixed configuration and the
per-process runtime configuration. The PreSpawnTarget method is still
used to configure the per-process configuration but it has pretty
much been refactored out as delegates tend to only configure the
fixed configuration. This CL also changes the PreSpawnChild method of
the ContentBrowserClient class to take the TargetConfig instead of the
TargetPolicy.
Bug: 1421105
Change-Id: Ie0bb3229830bcdcbeb883e0c8f655ec7d1b1c97c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4305339
Commit-Queue: James Forshaw <forshaw@chromium.org>
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1112925}
This is a reland of commit 2548a5c354
Compared to the original CL, this fixes the use of an uninit variable in
child_process_launcher_helper_posix.cc (region should be initialized to
kWholeFile if passing a file descriptor to the new process).
Original change's description:
> Linux: Fix zygote's use of base::FileDescriptorStore
>
> See crbug.com/1407326. This fixes (2) and adds a test to
> utility_process_host_browsertest.cc to ensure that this works in the
> future, with both the unsandboxed and the generic zygote.
>
> Unfortunately base::FileDescriptorStore still doesn't work on Android,
> so add a bug and a TODO to fix that.
>
> Bug: 692619, 1407326
>
> Change-Id: I83ecbb1ec84b36c55ed954acdbab890cb8f55862
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4166816
> Reviewed-by: Tom Sepez <tsepez@chromium.org>
> Commit-Queue: Matthew Denton <mpdenton@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1095906}
Bug: 692619, 1407326
Change-Id: Iad498b2949f4cc29d683f20cd4711fe2d4403656
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4191378
Commit-Queue: Matthew Denton <mpdenton@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1096462}
See crbug.com/1407326. This fixes (2) and adds a test to
utility_process_host_browsertest.cc to ensure that this works in the
future, with both the unsandboxed and the generic zygote.
Unfortunately base::FileDescriptorStore still doesn't work on Android,
so add a bug and a TODO to fix that.
Bug: 692619, 1407326
Change-Id: I83ecbb1ec84b36c55ed954acdbab890cb8f55862
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4166816
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Matthew Denton <mpdenton@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1095906}
ZygoteHandle being typedef'd as a pointer interfered with our ability
to use raw_ptr. There doesn't seem to have been much reason to have
ZygoteHandle at all as it just obscures that it's a ZygoteCommunication*
so this CL just deletes it and uses ZygoteCommunication*.
If other platforms need to introduce a Zygote they can either introduce
their own ZygoteCommunication or resurrect ZygoteHandle.
Bug: 1407326
Change-Id: Ia65a8e05468047dbc1748035356d237e0fe2c79d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4167265
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Matthew Denton <mpdenton@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Derek Schuff <dschuff@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1093662}
SandboxedProcessLauncherDelegate gains a method GetSandboxTag().
Delegates use this to return a string which is opaque to SandboxWin
but should uniquely identify the TargetConfig configuration that will
be applied to TargetPolicy. Delegates that do not wish to fix any
part of the policy can return an empty string.
SandboxWin gains a method GetSandboxTagForDelegate to simplify creating
different tags for delegates that use the same sandbox type but a
different process host - the assumption is that a utility in kGpu
might want different behavior to the gpu process and it's safer to
make it easy to use distinct policies in these cases.
This enables shared fixed policy configs for most processes, but as no
backing data is yet shared has little practical effect.
Bug: 549319
Change-Id: I17d1f817c2b750d9789c0c989c1dbc139e5146ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3556185
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: Mark Seaborn <mseaborn@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1027531}
sandbox.mojom.Sandbox can now be used as the sandbox type so we
replace it everywhere.
The guts of the change are in //sandbox/policy/sandbox_type.h where
SandboxType is now deleted, and //sandbox/policy/mojom/sandbox.mojom
where sandbox types that are not already used in mojom ServiceSandbox
attributes are added.
Some cascading changes:-
- kService wasn't implemented on Mac (as it is equivalent to kUtility).
As we cannot alias enum fields in mojo like we can in C++ I have added
kService for Mac. The alternative is to define platform specific
ServiceSandbox attributes for all kService interfaces which seems to
put this complexity in the wrong place.
- sandbox_type.h included a number of buildflag headers that other files
then relied on. As sandbox_type.h is no longer needed in many places
and no longer needs these defines, they have been introduced where
required.
- sandbox::mojom::Sandbox is forward declared in a couple of headers
that are widely imported, hopefully reducing the number of times the
mojom.h is included but not used.
- some build deps must be modified.
- LibAssistantService needs a sandbox to be defined even when hosted
in process, so has kNoSandbox now when enable_cros_libassistant is
false.
Bug: 1210301
Change-Id: I13fa4fa8cbbb3090a38806fe5532787bbdf1e2fb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3213677
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Reviewed-by: Filip Gorski <fgorski@chromium.org>
Reviewed-by: Derek Schuff <dschuff@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Tao Wu <wutao@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: Matthew Denton <mpdenton@chromium.org>
Reviewed-by: David Dorwin <ddorwin@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#934126}
Adds a way for the utility sandboxed launcher delegate in content
to to if a utility is compatible with CET.
The UtilWin service runs with SandboxType::kNoSandbox but as it
sometimes loads third party dlls (such as shell extensions) it may
crash when Hardware-enforced stack protection / Control-flow
Enforcement Technology (CET) is enabled. As this is a Chrome service
and does not have a unique sandbox type we must provide a way for
Chrome to indicate that this particular utility should run with CET
disabled. This trades increased stability for reduced security, but
the utility should not be exposed directly to untrusted data, so this
is a reasonable tradeoff.
Tests: browser_tests on supported hardware + manual tests (see bug).
Bug: 1200902
Change-Id: Iefab3dc34dfb16ba350c7a19b0a688a77dc724cd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2842082
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#875470}
The CDM service no longer needs to have shadow stack protection
turned off, so we can return to the default 'true' value for
CetCompatible() for all utility processes.
Bug: 1173700
Change-Id: I3a75135583896e1db002dc4a3b2c15e639527c95
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2800495
Reviewed-by: Will Harris <wfh@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#871112}
widevinecdm.dll is not compliant with CET and will crash when a user
attempts to play protected content. This adds a workaround to turn off
CET for the CDM service that hosts widevinecdm.dll. The workaround can
be removed once widevinecdm.dll has been fixed.
Bug: 1173700
Tests: mini_installer confirms CET disabled for CDM service
Change-Id: I38cb30cdc6052675d7678ae2161f7a0036da00cc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2676392
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#851417}
This locks the network sandbox to only allow what is needed to
function correctly.
It places Network Service process at UNTRUSTED integrity and
USER_LIMITED token level. This token level allows access to the
DNS service. In order for this to work, a few intercepts
must be landed which are:
- RW access to user_data directory for the disk cache and other
network files (e.g. TransportSecurity, Network Persistent State,
Reporting and NEL databases).
- RO access to registry policy paths needed for DNS, as these
are ACLed differently from the rest of HKLM hive.
- RO access to \DEVICE\\NETBT_TCPIP\* needed for network interface
enumeration.
The sandbox is gated behind "NetworkServiceSandbox" feature flag
and only enabled on Windows 10 and above.
This CL also fixes up one case where sandbox-type was being used to
control network service launch behavior, removes the exception
for strict handle checks that was added for issue 939590, ensures
that unsandboxed network processes continue to launch in a job
object where available on the platform, and removes an
unneeded global.
BUG=841001,939590,1166831
Change-Id: I3387819f439434d0898f7032b99227ba227cde71
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2645644
Commit-Queue: Will Harris <wfh@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Alex Gough <ajgo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#850388}
On mac-arm64, allow the x86_64 Widevine content decryption module (CDM)
to run under Rosetta translation, even when running native arm64 Chrome.
This is necessary because there isn’t currently an arm64-native Widevine
CDM. It’s not necessary to run the rest of Chrome as x86_64 under
Rosetta translation. The isolated Widevine CDM runs in its own x86_64
utility process, and is IPC-compatible with the rest of Chrome. This
alleviates any performance impact on the rest of Chrome, and allows
crash reporting to work correctly for the rest of Chrome.
An ordinary build of Chrome for mac-arm64, even an official build, will
not include a bundled x86_64 Widevine CDM library (or, obviously, an
arm64 one, as it does not yet exist). The x86_64 Widevine library is
useless to an arm64 Chrome without an x86_64 process to host it.
However, if a universal build of Chrome is created by merging
same-version x86_64 and arm64 builds, the arm64 code will look for an
x86_64 Widevine CDM and, if found, launch an x86_64 helper process under
Rosetta translation to host it.
https://chromium-review.googlesource.com/c/2515521/ is a proposal for
creating such a universal build.
Implementation notes: if no Widevine CDM library is found in the arm64
platform-specific location, Chrome on mac-arm64 will look for one in the
x86_64 platform-specific location. This allows mac-arm64 Chrome to find
the x86_64-only bundled Widevine library. Separately, any Widevine
library found will be examined to determine its architecture. If it
contains x86_64 code and no arm64 code, an x86_64 helper will be
launched to host it. This is done because, although the Widevine library
bundled in Chrome is known to be x86_64-only and will only exist in the
x86_64 platform-specific location, it is expected that a future update
distributed by the component updater will support arm64 natively.
However, in the event that a component update is produced that supports
x86_64 but not yet arm64, it is likely that the x86_64 version
distributed to arm64 users as a component update will appear in the
arm64 platform-specific location, despite being x86_64 code. This means
that the platform-specific location path cannot be trusted to convey the
actual architecture of the library contained therein, and the
architecture must be determined by examining the library to be loaded.
No behavior change for non-mac-arm64 builds.
Bug: 1142017
Code-Word: calamity
CQ-Include-Trybots: luci.chromium.try:mac-arm64-rel
Change-Id: Ib3f4a654f89f41c0fbf9239f99010387ea242763
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2493191
Commit-Queue: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Auto-Submit: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Joshua Pawlicki <waffles@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#823801}
No functional changes.
- Change DEPS for network sandbox specialization
- _win.cc as much code is Windows only and could have distinct reviewers.
- Setup OWNERS for new files to ensure review.
Bug: 1111421
Change-Id: I03e5e0c4e4df87d3af9e5ce58975b3d4348ce90a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2332860
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#794840}
