1bbda7e662
The application zygote is a new sort of zygote process that is a child of the regular zygote. Each application zygote is tied to the application for which it's launched. Once it's started, it will pre-load some of the code for that specific application, much like the regular zygote does for framework code. Once the application zygote is up and running, it can spawn isolated service processes that run in the isolated_app domain. These services can then benefit from already having the relevant application code and data pre-loaded. The policy is largely the same as the webview_zygote domain, however there are a few crucial points where the policy is different. 1) The app_zygote runs under the UID of the application that spawned it. 2) During app_zygote launch, it will call a callback that is controlled by the application, that allows the application to pre-load code and data that it thinks is relevant. Especially point 2 is imporant: it means that untrusted code can run in the app_zygote context. This context is severely limited, and the main concern is around the setgid/setuid capabilities. Those conerns are mitigated by installing a seccomp filter that only allows setgid/setuid to be called in a safe range. Bug: 111434506 Test: app_zygote can start and fork children without denials. Change-Id: I1cc49ee0042d41e5ac6eb81d8f8a10ba448d4832
5 lines
219 B
Text
5 lines
219 B
Text
# app_zygote is an auxiliary zygote process that is used to spawn
|
|
# isolated service processes for individual applications. It is
|
|
# spawned from the regular zygote process as a "child zygote".
|
|
|
|
type app_zygote, domain;
|