A service needs to be able to run code before the sandbox is turned-on. |
|||
Issue descriptionSome services, such as MediaGalleryUtilService (chrome/services/media_gallery_util), require some initializations to be performed before the sandbox is turned on. At this time, it happens as part of the utility process set-up through the ContentMainDelegate::PreSandboxStartup() call: ContentMainRunnerImpl::Initialize() content/app/content_main_runner.cc ChromeMainDelegate::PreSandboxStartup() chrome/app/chrome_main_delegate.cc ChromeContentUtilityClient::PreSandboxStartup() chrome/utility/chrome_content_utility_client.cc extensions::PreSandboxStartup() chrome/utility/extensions/extensions_handler.cc media::InitializeMediaLibrary() media/base/media.cc As part of moving utility process launching to the service manager, we need to find a way for a service to run some specific code before the sandbox's initialization. Some early ideas: - specify in the service's manifest the symbol name of pre-sandbox init method that is run early on (not sure if we can actually access that method with dlsym if it is not in the main program but in an .so) - delay the sandbox start-up until after the service manager has connected to the other process and the service bind request
,
Mar 15 2018
A few random thoughts: - I'm wary of letting services run arbitrary code of their choosing before the sandbox is engaged, since the potential for introducing security bugs is quite high. Any mechanism should have a way to ensure a security review is required. - On Linux, the zygote will complicate matters: there can be pre-seccomp sandbox warmup work, but the zygote will place the new process into a namespace (the outer-layer sandbox) that will restrict the filesystem access. - On Mac, the concept of pre-sandbox warmup no longer exists (see issue 749839). The process is sandboxed before the first line of ChromeMain. - Is this something that really needs to be generified, or is this a one-off use case? - Are there alternate approaches that would obviate the need for a warmup (e.g. resource brokering)?
,
Mar 15 2018
,
Mar 15 2018
There are couple of things done in PreSandboxStartup() by the different implementations: - some resource bundle initializations (mostly using mmap on a file descriptor passed in, so I assume this should be OK sandboxed) - enabling crash reporting. Not sure if that works in the sandbox, but even if it doesn't it should probably be supported at the service manager level, so this should not be a problem - init some CPU info structure (by potentially reading /proc). This is done for the FFMPEG libavutil third-party lib. The real problematic one would be getting the CPU info, but since it's a one-off case, it would probably be easier to change that code to get that CPU info passed in. So I think you are right: it's better to work toward removing pre-sandbox warm-up from the embedder layer and use resource brokering (or move things to the non-embedder layer, such as for crash reporting). I'll file a bug and will try that. |
|||
►
Sign in to add a comment |
|||
Comment 1 by jcivelli@chromium.org
, Mar 15 2018