I'm pretty skeptical about the idea of creating a platform-agnostic declaration of the sandbox policies. Sandboxing is extremely platform-specific and is more than just lists of files or even system services that need to be accessed. Sometimes APIs need to be warmed up or invoked in specific ways to make them more amenable to sandboxing. And there are other cases where we restrict certain arguments or classes that are entirely platform-specific. Creating an abstraction over these platform-specific concerns seems complicated. (And on Mac, we already express our sandbox profiles declaratively, so I wouldn't want to build a layer on top of it in the first place.)

In a discussion with wfh@, he mentioned that forshaw@ is exploring writing Windows sandbox policies in a configuration language rather than code. So for Mac and Windows, the service manifest could possibly point to platform-specific sandbox policy files.

However, the Linux Seccomp sandbox already has a C++ DSL for expressing the policies, and there's no plan to move away from that. On ChromeOS, there is Minijail, which is a text-base DSL for writing Seccomp policies. But it's nowhere near as expressive as we need on Linux/CrOS/Android. As an example, for certain system calls, we make policy decisions based on runtime characteristics (https://cs.chromium.org/chromium/src/sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc?l=130&rcl=1b404351c0a3571958e12b61409358fbdd81df50).

From a security perspective, the sandbox is an implementation detail of the service implementation, and that is a good thing. We don't want to create generic, loose-fitting sandboxes. Ideally the sandbox is tailor-made to the code being executed so that the process has only the resources it needs to do the job and not an allowance more. High-level it seems like we ought to be able to create capability-based sandbox profiles, but in practice my experience is that the policy implementation doesn't lend itself to that.

The windows sandbox policy design lends itself to the possibility of moving the configuration from code to some kind of DSL - forshaw@ is investigating this but given he's only 20% on Chrome Security, we can't really give any timelines.

I agree with rsesek that trying to unify across multiple platforms will probably make things more complex and less maintainable rather than the other way round, but I do see potential for per-platform.

Let me ask a different question then: are we doing it wrong by having
sandbox type specified in the service manifest, apart from being
informative to reviewers?

Does the Service Manager actually need to know about sandbox type? Is there
sandbox setup work done by the process launcher, or is it all done within
launched process before it operates on potentially untrusted code/data?
I've always assumed it was a bit of both but I admit I haven't looked too
closely on all platforms.

My main concern here is that having to hard-code launcher-side,
service-specific sandbox setup logic into the Service Manager cannot scale.
If we can at least generalize a suite of sandbox configuration types that
would still be better than having "ppapi", "network", "cdm",
"pdf_compositor" (yikes), "audio", etc.

>Does the Service Manager actually need to know about sandbox type? 

(Note: I'm speaking for Windows, I cannot comment on other OS, they may be the same, or different, in subtle ways)

Yes, the service manager is responsible for calling the right PreSpawnTarget and also for setting up the right SandboxedProcessLauncherDelegate - the policies are currently represented in code, but the determination of which delegate to use is done by reading the manifest which translates to a service_manager::SandboxType.

I agree service manager doesn't need to know the complexities of the policies, but it does need to (currently) know which code to call in the delegates to set up the right policies.

I'm not sure where else this configuration be held other than in the service manifest...?

Yeah, just confirming to make sure I wasn't trying to solve an unnecessary
problem. Manifest makes sense if there's launcher-side configuration to be
done.

FWYW - Yes, I agree that it would be nice to solve the problem of having the service manager have to understand that e.g. "audio" sandbox type means that it needs to call "audio::AudioPreSandboxHook" and e.g. on macOS is needs to add the "service_manager::kSeatbeltPolicyString_audio" seatbelt policy, and all sorts of other things 'hard coded' into .cc files.

James's work, from what I know of it, is concentrated on turning the hard coded policy calls e.g. removing calls currently written in .cc files to set specific mitigation flags [1] , or add particular file/reg policies [2] or job levels [3] and putting these in some kind of configuration file that will [insert magic] result in autogenerated code for the same functions - there will still need to be some kind of mapping between the service manager's concept of 'audio' as a sandbox type, and this code (wherever it ends up living). Given currently these calls are spread all over the place (some in presandbox, some in main sandbox_win.cc, some elsewhere) this is potentially quite a large task.

[1] e.g. SANDBOX_TYPE_NETWORK/AUDIO specific code - https://cs.chromium.org/chromium/src/services/service_manager/sandbox/win/sandbox_win.cc?l=921
[2] e.g. SANDBOX_TYPE_NETWORK specific code - https://cs.chromium.org/chromium/src/services/network/network_sandbox_win.cc?l=133
[3] e.g. SANDBOX_TYPE_XRCOMPOSITING specific code - https://cs.chromium.org/chromium/src/content/browser/utility_process_host.cc?l=153

> Does the Service Manager actually need to know about sandbox type?

On Mac and Linux too, the thing launching the sandboxed process does need to configure the sandbox before the actual launch.