Add SELinux policy for storage areas
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
diff --git a/private/app.te b/private/app.te
index 634cc53..30931e4 100644
--- a/private/app.te
+++ b/private/app.te
@@ -242,12 +242,37 @@
allow appdomain surfaceflinger:unix_stream_socket { read write setopt getattr getopt shutdown };
# App sandbox file accesses.
-allow { appdomain -isolated_app_all -mlstrustedsubject -sdk_sandbox_all } { app_data_file privapp_data_file }:dir create_dir_perms;
-allow { appdomain -isolated_app_all -mlstrustedsubject -sdk_sandbox_all } { app_data_file privapp_data_file }:file create_file_perms;
-allowxperm { appdomain -isolated_app_all -mlstrustedsubject -sdk_sandbox_all } { app_data_file privapp_data_file }:file ioctl FS_IOC_MEASURE_VERITY;
+allow { appdomain -isolated_app_all -mlstrustedsubject -sdk_sandbox_all } {
+ app_data_file
+ privapp_data_file
+ is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `storage_area_content_file')
+}:dir create_dir_perms;
+allow { appdomain -isolated_app_all -mlstrustedsubject -sdk_sandbox_all } {
+ app_data_file
+ privapp_data_file
+ is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `storage_area_content_file')
+}:file create_file_perms;
+
+is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `
+ # an app can read but cannot write to its own directory of storage areas
+ allow { appdomain -isolated_app_all -mlstrustedsubject -sdk_sandbox_all } storage_area_app_dir:dir r_dir_perms;
+ # an app can write to its storage areas
+ allow { appdomain -isolated_app_all -mlstrustedsubject -sdk_sandbox_all } storage_area_dir:dir rw_dir_perms;
+')
+
+allowxperm { appdomain -isolated_app_all -mlstrustedsubject -sdk_sandbox_all } {
+ app_data_file
+ privapp_data_file
+ is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `storage_area_content_file')
+}:file ioctl FS_IOC_MEASURE_VERITY;
# Access via already open fds is ok even for mlstrustedsubject.
-allow { appdomain -isolated_app_all -sdk_sandbox_all } { app_data_file privapp_data_file system_app_data_file }:file { getattr map read write };
+allow { appdomain -isolated_app_all -sdk_sandbox_all } {
+ app_data_file
+ privapp_data_file
+ system_app_data_file
+ is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `storage_area_content_file')
+}:file { getattr map read write };
# Access open fds from SDK sandbox
allow appdomain sdk_sandbox_data_file:file { getattr read };
@@ -777,3 +802,13 @@
neverallow appdomain system_font_fallback_file:file no_rw_file_perms;
neverallow { appdomain -shell } tombstone_data_file:file ~{ getattr read };
+is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `
+ # Files and directories that apps write to their storage areas
+ # should have type storage_area_content_file
+ type_transition {
+ appdomain
+ -isolated_app_all
+ -ephemeral_app
+ -sdk_sandbox_all
+ } storage_area_dir:{ notdevfile_class_set dir } storage_area_content_file;
+')