- Feb 11, 2014
-
-
Robert Craig authored
This new type will allow us to write finer-grained policy concerning asec containers. Some files of these containers need to be world readable. Change-Id: Iefee74214d664acd262edecbb4f981d633ff96ce Signed-off-by:
rpcraig <rpcraig@tycho.ncsc.mil>
-
- Jan 11, 2014
-
-
Nick Kralevich authored
Permissive domains are only intended for development. When a device launches, we want to ensure that all permissive domains are in, at a minimum, unconfined+enforcing. Add FORCE_PERMISSIVE_TO_UNCONFINED to Android.mk. During development, this flag is false, and permissive domains are allowed. When SELinux new feature development has been frozen immediately before release, this flag will be flipped to true. Any previously permissive domains will move into unconfined+enforcing. This will ensure that all SELinux domains have at least a minimal level of protection. Unconditionally enable this flag for all user builds. Change-Id: I1632f0da0022c80170d8eb57c82499ac13fd7858
-
- Oct 23, 2013
-
-
Stephen Smalley authored
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>
-
- Oct 21, 2013
-
-
Nick Kralevich authored
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
-
- Jul 13, 2013
-
-
Nick Kralevich authored
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
-