As has already been done for untrusted_app, isolated_app,
and bluetooth, make all the other domains used for app
processes confined while making them permissive until sufficient
testing has been done.
Change-Id: If55fe7af196636c49d10fc18be2f44669e2626c5
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This change removes the permissive line from unconfined
domains. Unconfined domains can do (mostly) anything, so moving
these domains into enforcing should be a no-op.
The following domains were deliberately NOT changed:
1) kernel
2) init
In the future, this gives us the ability to tighten up the
rules in unconfined, and have those tightened rules actually
work.
When we're ready to tighten up the rules for these domains,
we can:
1) Remove unconfined_domain and re-add the permissive line.
2) Submit the domain in permissive but NOT unconfined.
3) Remove the permissive line
4) Wait a few days and submit the no-permissive change.
For instance, if we were ready to do this for adb, we'd identify
a list of possible rules which allow adbd to work, re-add
the permissive line, and then upload those changes to AOSP.
After sufficient testing, we'd then move adb to enforcing.
We'd repeat this for each domain until everything is enforcing
and out of unconfined.
Change-Id: If674190de3262969322fb2e93d9a0e734f8b9245
app.te covers a lot of different apps types (platform_app, media_app,
shared_app, release_app, isolated_app, and untrusted_app), all
of which are going to have slightly different security policies.
Separate the different domains from app.te. Over time, these
files are likely to grow substantially, and mixing different domain types
is a recipe for confusion and mistakes.
No functional change.
Change-Id: Ida4e77fadb510f5993eb2d32f2f7649227edff4f
