tequilaOS/platform_system_sepolicy
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_system_sepolicy/public/untrusted_app.te

22 lines
982 B
Text
Raw Normal View History

Move *_app into their own file 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
2013-07-13 01:33:29 +02:00
###
### Untrusted apps.
###
Clarify meaning of untrusted_app and app domain assignment logic. The current inline documentation is not entirely accurate and caused user confusion, e.g. see: https://groups.google.com/d/msg/android-security-discuss/javBrPT8ius/C4EVEFUu4ZoJ Try to clarify the meaning of untrusted_app, how app domains are assigned, and how to move other system apps out of untrusted_app into a different domain. Change-Id: I98d344dd078fe9e2738b68636adaabda1f4b3c3a Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2014-02-21 19:26:20 +01:00
### Apps are labeled based on mac_permissions.xml (maps signer and
### optionally package name to seinfo value) and seapp_contexts (maps UID
### and optionally seinfo value to domain for process and type for data
### directory). The untrusted_app domain is the default assignment in
### seapp_contexts for any app with UID between APP_AID (10000)
### and AID_ISOLATED_START (99000) if the app has no specific seinfo
### value as determined from mac_permissions.xml. In current AOSP, this
### domain is assigned to all non-system apps as well as to any system apps
Coalesce shared_app, media_app, release_app into untrusted_app. This change folds the shared_app, media_app, and release_app domains into untrusted_app, reducing the set of app domains down to just distinct domains for the fixed UID apps (e.g. system_app, bluetooth, nfc, radio), a single domain for apps signed by the platform key (platform_app), and a single domain for all other apps (untrusted_app). Thus, SELinux only distinguishes when already distinguished by a predefined Android ID (AID) or by the platform certificate (which get the signature-only Android permissions and thus may require special OS-level accesses). It is still possible to introduce specific app domains for specific apps by adding signer and package stanzas to mac_permissions.xml, but this can be done on an as-needed basis for specialized apps that require particular OS-level permissions outside the usual set. As there is now only a single platform app domains, get rid of the platformappdomain attribute and platform_app_domain() macro. We used to add mlstrustedsubject to those domains but drop this since we are not using MLS in AOSP presently; we can revisit which domains need it if/when we use MLS. Since we are dropping the shared, media, and release seinfo entries from seapp_contexts, drop them from mac_permissions.xml as well. However, we leave the keys.conf entries in case someone wants to add a signer entry in the future for specific apps signed by those keys to mac_permissions.xml. Change-Id: I877192cca07360c4a3c0ef475f016cc273e1d968 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2014-04-04 15:09:25 +02:00
### that are not signed by the platform key. To move
Clarify meaning of untrusted_app and app domain assignment logic. The current inline documentation is not entirely accurate and caused user confusion, e.g. see: https://groups.google.com/d/msg/android-security-discuss/javBrPT8ius/C4EVEFUu4ZoJ Try to clarify the meaning of untrusted_app, how app domains are assigned, and how to move other system apps out of untrusted_app into a different domain. Change-Id: I98d344dd078fe9e2738b68636adaabda1f4b3c3a Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2014-02-21 19:26:20 +01:00
### a system app into a specific domain, add a signer entry for it to
### mac_permissions.xml and assign it one of the pre-existing seinfo values
### or define and use a new seinfo value in both mac_permissions.xml and
### seapp_contexts.
Move *_app into their own file 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
2013-07-13 01:33:29 +02:00
###
Remove domain_deprecated from untrusted_app. Bug: 22032619 Change-Id: Iaa192f98df3128da5e11ce1fd3cf9d1a597fedf5
2016-01-23 00:51:41 +01:00
type untrusted_app, domain;
Add untrusted_app_27 This is a partial cherry pick of commit 6231b4d9 'Enforce per-app data protections for targetSdk 28+'. Untrusted_app_27 remains unreachable, but it's existence prevents future merge conflicts. Bug: 63897054 Test: build/boot aosp_walleye-userdebug Change-Id: I64b013874fe87b55f47e817a1279e76ecf86b7c0 Merged-In: I64b013874fe87b55f47e817a1279e76ecf86b7c0 (cherry picked from commit 6231b4d9fc98bb42956198e9f54cabde69464339)
2018-04-03 20:22:38 +02:00
type untrusted_app_27, domain;
type untrusted_app_25, domain;
Reference in a new issue Copy permalink