Restrict creating per-user encrypted directories
Creating a per-user encrypted directory such as /data/system_ce/0 and
the subdirectories in it too early has been a recurring bug. Typically,
individual services in system_server are to blame; system_server has
permission to create these directories, and it's easy to write
"mkdirs()" instead of "mkdir()". Such bugs are very bad, as they
prevent these directories from being encrypted, as encryption policies
can only be set on empty directories. Due to recent changes, a factory
reset is now forced in such cases, which helps detect these bugs;
however, it would be much better to prevent them in the first place.
This CL locks down the ability to create these directories to just vold
and init, or to just vold when possible. This is done by assigning new
types to the directories that contain these directories, and then only
allowing the needed domains to write to these parent directories. This
is similar to what https://r.android.com/1117297 did for /data itself.
Three new types are used instead of just one, since these directories
had three different types already (system_data_file, media_rw_data_file,
vendor_data_file), and this allows the policy to be a bit more precise.
A significant limitation is that /data/user/0 is currently being created
by init during early boot. Therefore, this CL doesn't help much for
/data/user/0, though it helps a lot for the other directories. As the
next step, I'll try to eliminate the /data/user/0 quirk. Anyway, this
CL is needed regardless of whether we're able to do that.
Test: Booted cuttlefish. Ran 'sm partition disk:253,32 private', then
created and deleted a user. Used 'ls -lZ' to check the relevant
SELinux labels on both internal and adoptable storage. Also did
similar tests on raven, with the addition of going through the
setup wizard and using an app that creates media files. No
relevant SELinux denials seen during any of this.
Bug: 156305599
Change-Id: I1fbdd180f56dd2fe4703763936f5850cef8ab0ba
diff --git a/private/file_contexts b/private/file_contexts
index af51799..0c45a88 100644
--- a/private/file_contexts
+++ b/private/file_contexts
@@ -563,7 +563,8 @@
/data/local/tmp(/.*)? u:object_r:shell_data_file:s0
/data/local/tmp/ltp(/.*)? u:object_r:nativetest_data_file:s0
/data/local/traces(/.*)? u:object_r:trace_data_file:s0
-/data/media(/.*)? u:object_r:media_rw_data_file:s0
+/data/media u:object_r:media_userdir_file:s0
+/data/media/.* u:object_r:media_rw_data_file:s0
/data/mediadrm(/.*)? u:object_r:media_data_file:s0
/data/nativetest(/.*)? u:object_r:nativetest_data_file:s0
/data/nativetest64(/.*)? u:object_r:nativetest_data_file:s0
@@ -580,6 +581,12 @@
/data/rollback/\d+/[^/]+/.*\.apk u:object_r:apk_data_file:s0
/data/rollback/\d+/[^/]+/.*\.apex u:object_r:staging_data_file:s0
/data/fonts/files(/.*)? u:object_r:font_data_file:s0
+/data/misc_ce u:object_r:system_userdir_file:s0
+/data/misc_de u:object_r:system_userdir_file:s0
+/data/system_ce u:object_r:system_userdir_file:s0
+/data/system_de u:object_r:system_userdir_file:s0
+/data/user u:object_r:system_userdir_file:s0
+/data/user_de u:object_r:system_userdir_file:s0
# Misc data
/data/misc/adb(/.*)? u:object_r:adb_keys_file:s0
@@ -665,8 +672,10 @@
/data/misc/profiles/ref(/.*)? u:object_r:user_profile_data_file:s0
/data/misc/profman(/.*)? u:object_r:profman_dump_data_file:s0
/data/vendor(/.*)? u:object_r:vendor_data_file:s0
-/data/vendor_ce(/.*)? u:object_r:vendor_data_file:s0
-/data/vendor_de(/.*)? u:object_r:vendor_data_file:s0
+/data/vendor_ce u:object_r:vendor_userdir_file:s0
+/data/vendor_ce/.* u:object_r:vendor_data_file:s0
+/data/vendor_de u:object_r:vendor_userdir_file:s0
+/data/vendor_de/.* u:object_r:vendor_data_file:s0
# storaged proto files
/data/misc_de/[0-9]+/storaged(/.*)? u:object_r:storaged_data_file:s0
@@ -721,8 +730,17 @@
#############################
# Expanded data files
#
-/mnt/expand(/.*)? u:object_r:mnt_expand_file:s0
-/mnt/expand/[^/]+(/.*)? u:object_r:system_data_file:s0
+/mnt/expand u:object_r:mnt_expand_file:s0
+# CAREFUL: the two system_data_file patterns below can't be replaced with one
+# pattern "/mnt/expand/[^/]+(/.*)?", since SELinux would prioritize that over
+# "/mnt/expand/[^/]+/user". This is because when a path is matched by two
+# patterns that contain regex meta-characters, SELinux just chooses the longer
+# pattern (or the later pattern if the patterns are the same length), rather
+# than the pattern containing fewer regex meta-characters. Splitting the
+# pattern into "/mnt/expand/[^/]+" and "/mnt/expand/[^/]+/.*" works around this
+# problem, except for 1-character filenames which we aren't using.
+/mnt/expand/[^/]+ u:object_r:system_data_file:s0
+/mnt/expand/[^/]+/.* u:object_r:system_data_file:s0
/mnt/expand/[^/]+/app(/.*)? u:object_r:apk_data_file:s0
/mnt/expand/[^/]+/app/[^/]+/oat(/.*)? u:object_r:dalvikcache_data_file:s0
# /mnt/expand/..../app/[randomStringA]/[packageName]-[randomStringB]/base.apk layout
@@ -730,8 +748,13 @@
/mnt/expand/[^/]+/app/vmdl[^/]+\.tmp(/.*)? u:object_r:apk_tmp_file:s0
/mnt/expand/[^/]+/app/vmdl[^/]+\.tmp/oat(/.*)? u:object_r:dalvikcache_data_file:s0
/mnt/expand/[^/]+/local/tmp(/.*)? u:object_r:shell_data_file:s0
-/mnt/expand/[^/]+/media(/.*)? u:object_r:media_rw_data_file:s0
+/mnt/expand/[^/]+/media u:object_r:media_userdir_file:s0
+/mnt/expand/[^/]+/media/.* u:object_r:media_rw_data_file:s0
/mnt/expand/[^/]+/misc/vold(/.*)? u:object_r:vold_data_file:s0
+/mnt/expand/[^/]+/misc_ce u:object_r:system_userdir_file:s0
+/mnt/expand/[^/]+/misc_de u:object_r:system_userdir_file:s0
+/mnt/expand/[^/]+/user u:object_r:system_userdir_file:s0
+/mnt/expand/[^/]+/user_de u:object_r:system_userdir_file:s0
# coredump directory for userdebug/eng devices
/cores(/.*)? u:object_r:coredump_file:s0