We are adding the ability for apps to create "storage areas", which are
transparently encrypted directories that can only be opened when the
device is unlocked.
This CL makes the required SELinux policy changes.
First, assign the type "system_userdir_file" to the new top-level
directory /data/storage_area (non-recursively). This is the same type
used by the other top-level directories containing app data, such as
/data/user, and it restricts access to the directory in the desired way.
Second, add new types to represent an app's directory of storage areas,
the storage areas themselves, and their contents:
`storage_area_app_dir`, `storage_area_dir`, and
`storage_area_content_file` respectively.
All are `app_data_file_type`s.
The directory structure and their associated labels is as follows (note
that they also all get the categories of the user+package):
/data/storage_area/userId/pkgName
storage_area_app_dir
/data/storage_area/userId/pkgName/storageAreaName
storage_area_dir
/data/storage_area/userId/pkgName/storageAreaName/myFile.txt
storage_area_content_file
/data/storage_area/userId/pkgName/storageAreaName/mySubDir
storage_area_content_file
These new types allow us to restrict how and which processes interact
with storage areas.
The new type for the contents of storage areas allows us to add new,
desirable restrictions that we cannot add to the more general
`app_data_file` type in order to maintain backwards-compatibility,
e.g., we block apps from executing any files in their storage areas.
Third, allow:
-- vold_prepare_subdirs to create and delete
storage areas on behalf of apps, and assign them the SElinux type
`storage_area_dir`
i.e. create directories
/data/storage_area/$userId/$pkgName/$storageAreaName
-- vold to assign encryption policies to storage area directories
-- installd to create an app's directory of storage areas on app
install, and delete them on app uninstall, and assign them the SElinux
type `storage_area_app_dir`,
i.e. directories /data/storage_area/$userId/$pkgName
We also add a new SELinux type to represent the storage area encryption
keys: `storage_area_key_file`.
The keys are created by vold on storage area creation, and deleted
either by vold if an app calls
the `deleteStorageArea` API function explicitly, or by installd on
app uninstall.
These keys are stored in `/data/misc_ce/$userId/storage_area_keys`,
and only installd and vold have access to them.
Bug: 325121608
Test: atest StorageAreaTest
Change-Id: I74805d249f59226fc6963693f682c70949bfad93
Secondary dex files are in app data directories. In order to perform
secondary dex compilation, artd needs permissions to:
- Read secondary dex files
- Create "oat" dir
- Create a reference profile in "oat" dir
- Rename the reference profile
- Delete the reference profile
- Read the current profile in "oat" dir
- Delete the current profile
- Create compilation artifacts in "oat" dir
- Rename compilation artifacts
- Delete compilation artifacts
Bug: 249984283
Test: -
1. adb shell pm art optimize-package --secondary-dex -m speed-profile -f com.google.android.gms
2. See no SELinux denial.
Change-Id: I19a0ea7895a54c67959b22085de27d1d0ccc1efc
Remove references in sepolicy. Leave a few of the types defined since
they're public and may be used in device-specific policy.
Bug: 211461392
Test: build/boot cuttlefish
Change-Id: I615137b92b82b744628ab9b7959ae5ff28001169
It only accesses already-open file handles since b/67111829, so has no
need for any access to the directories, not even search access.
Fixes: 161960094
Bug: 141677108
Test: boot, install app
Test: cmd package force-dex-opt <package>
Test: cmd package bg-dexopt-job
Test: No denials seen.
Change-Id: I23dca1f038351be759dd16dff18d16d158604c3c
We have various apps which inherently work across all users,
configured in seapp_contexts with levelFrom=None (usually implicitly).
This change marks those apps, where they have private data files, as
mlstrustedsubject, to allow us to increase restrictions on cross-user
access without breaking them.
Currently these apps are granted full access to [priv_]app__data_file
via TE rules, but are blocked from calling open (etc) by mls rules
(they don't have a matching level).
This CL changes things round so they are granted access by mls, but
blocked from calling open by TE rules; the overall effect is thus the
same - they do not have access.
A neverallow rule is added to ensure this remains true.
Note that there are various vendor apps which are appdomain,
levelFrom=None; they will also need modified policy.
Test: builds, boots, no new denials.
Bug: 141677108
Change-Id: Ic14f24ec6e8cbfda7a775adf0c350b406d3a197e
