On 03/27/2014 04:07 PM, Tai Nguyen (tainguye) wrote:
> Thank - so in term of security, why do we need to treat them differently
> from untrusted app?
> Is it because it is customized for limited services instead of activities?
> Can we rely on Android framework to limit its communication?
Originally it was to distinguish them so that we did not attempt to
apply the levelFrom=app logic for those app UIDs, as they are not
mappable in any way to the app ID for the associated app, and we needed
to support any app using isolatedProcess=true and interacting with its
own isolated process.
At this point it is useful in that we are more likely to be able to
apply a more restrictive policy to isolated services than to other app
processes. For example, in AOSP master, isolated_app is already fully
confined+enforcing, whereas untrusted_app is still unconfined/permissive
until they are confident that there will be no compatibility breakage,
and in the policy, there are certain rules allowed for untrusted_app but
not isolated_app. We could further tighten up isolated_app by excluding
it from specific rules in app.te (e.g. writing the rule as 'allow {
appdomain -isolated_app } ...') that we know should never happen for an
isolated service, but that would require some investigation and testing.
