Enforce execve() restrictions for API > 28
untrusted_app: Remove the ability to run execve() on files within an
application's home directory. Executing code from a writable /home
directory is a W^X violation (https://en.wikipedia.org/wiki/W%5EX).
Additionally, loading code from application home directories violates a
security requirement that all executable code mapped into memory must
come from signed sources, or be derived from signed sources.
Note: this change does *not* remove the ability to load executable code
through other mechanisms, such as mmap(PROT_EXEC) of a file descriptor
from the app's home directory. In particular, functionality like
dlopen() on files in an app's home directory continues to work even
after this change.
untrusted_app_25 and untrusted_app_27: For backwards compatibility,
continue to allow these domains to execve() files from the
application's home directory.
seapp_contexts: Bump the minimum API level required to enter the
untrusted_app domain. This will run API level 27-28 processes in
the API level 27 sandbox. API level 28 will continue to run with
levelFrom=all, and API level 27 will continue to run with
levelFrom=user.
Bug: 112357170
Test: Device boots and no obvious problems.
Test: See CTS test at https://android-review.googlesource.com/c/platform/cts/+/804228
Change-Id: Ief9ae3a227d16ab5792f43bacbb577c1e70185a0
diff --git a/private/untrusted_app_all.te b/private/untrusted_app_all.te
index 54d278e..527216d 100644
--- a/private/untrusted_app_all.te
+++ b/private/untrusted_app_all.te
@@ -22,7 +22,7 @@
# Some apps ship with shared libraries and binaries that they write out
# to their sandbox directory and then execute.
-allow untrusted_app_all { app_data_file privapp_data_file }:file { rx_file_perms };
+allow untrusted_app_all { app_data_file privapp_data_file }:file { r_file_perms execute };
# ASEC
allow untrusted_app_all asec_apk_file:file r_file_perms;