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
Currently, both untrusted apps and priv-apps use the SELinux file label
"app_data_file" for files in their /data/data directory. This is
problematic, as we really want different rules for such files. For
example, we may want to allow untrusted apps to load executable code
from priv-app directories, but disallow untrusted apps from loading
executable code from their own home directories.
Commit 23c9d91b46 introduced a new type
called privapp_data_file and added rules necessary to preserve
compatibility. However, that change did not relabel any existing files,
so effectively the change was a no-op.
This change performs the switch, relabeling priv-app's /data/data files
from app_data_file to privapp_data_file. Due to the compatibility rules
added in 23c9d91b46, there should be no
noticeable effect from this change.
This change was originally submitted as
4df57822fc. However, it was reverted in
cdc6649acc due to a different labeling
bug. That bug has been fixed, and we can reapply this change.
Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
filesystem upgrade.
Bug: 112357170
There is a problem with on-disk labeling of files created by secondary
dex background compilation which is causing unexpected denials to show
up. Restore the old labeling until we are able to fix the underlying
problem.
Steps to reproduce:
1) boot android device.
2) adb root
3) Run cmd package compile -r bg-dexopt --secondary-dex com.google.android.gms
4) Examine the files in /data/user_de/0/com.google.android.gms
Expected:
All files have the label privapp_data_file
Actual:
The files in /data/user_de/0/com.google.android.gms/app_chimera/m
are labeled "app_data_file", not "privapp_data_file".
This reverts commit 4df57822fc.
Bug: 112357170
Test: policy compiles
Change-Id: I38ba75c92c9c46e6a1fdbc02e3dc80c63adccaa8
Currently, both untrusted apps and priv-apps use the SELinux file label
"app_data_file" for files in their /data/data directory. This is
problematic, as we really want different rules for such files. For
example, we may want to allow untrusted apps to load executable code
from priv-app directories, but disallow untrusted apps from loading
executable code from their own home directories.
Commit 23c9d91b46 introduced a new type
called privapp_data_file and added rules necessary to preserve
compatibility. However, that change did not relabel any existing files,
so effectively the change was a no-op.
This change performs the switch, relabeling priv-app's /data/data files
from app_data_file to privapp_data_file. Due to the compatibility rules
added in 23c9d91b46, there should be no
noticeable effect from this change.
Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
filesystem upgrade.
Merged-In: I9a476726bf01f4bcc7952d11fd57dba803a9fd8d
Change-Id: I23a26cd3906fc43cbd225c05c3a2abd3cab8bd06
This reverts commit bf0c2a59f8.
Bug:68126425
Test: No apps affected by not being able to run in shell domain
Change-Id: I8b93eecd023fbb392a98253d721dad75f79b61f4
Merged-In: I8b93eecd023fbb392a98253d721dad75f79b61f4
This reverts commit bf0c2a59f8.
Bug:68126425
Test: No apps affected by not being able to run in shell domain
Change-Id: I8b93eecd023fbb392a98253d721dad75f79b61f4
In this architecture, the system_server instructs the zygote to fork a
child-zygote to be the webview_zygote. The system_server tells this new
zygote to listen for fork requests on a random abstract unix socket of
its choosing.
A follow-up CL will remove the rules for starting webview_zygote via
init.
Bug: 63749735
Test: m
Test: Launch "Third-party licenses" activity from Settings, and it
renders correctly via the WebView.
Merged-In: I864743943c11c18de386010ecd4b616721cb9954
Change-Id: I1c352e47b66eca3a3fa641daa6ecc3e7a889b54e
In this architecture, the system_server instructs the zygote to fork a
child-zygote to be the webview_zygote. The system_server tells this new
zygote to listen for fork requests on a random abstract unix socket of
its choosing.
A follow-up CL will remove the rules for starting webview_zygote via
init.
Bug: 63749735
Test: m
Test: Launch "Third-party licenses" activity from Settings, and it
renders correctly via the WebView.
Change-Id: I864743943c11c18de386010ecd4b616721cb9954
Adds per-app categories to untrusted app domains and their
app data types. Per-app categories are in addition to the
existing per-user categories.
Apps targeting sdk version 28+ will now have the following
characteristics:
Domain: u:r:untrusted_app:s0:c[0-9]+,c[0-9]+,c[0-9],c[0-9]
Data context: u:object_r:app_data_file:s0:c[0-9]+,c[0-9]+,c[0-9],c[0-9]
Whereas apps targeting 27- will look like:
Domain: u:r:untrusted_app_27:s0:c[0-9]+,c[0-9]+
Data context: u:object_r:app_data_file:s0:c[0-9]+,c[0-9]+
To ensure backwards compatibility with previous SDK versions,
the levelFrom=all now enforces categories by dominance instead of
equality. Apps with per-app and per-user categories will continue
to have selinux permissions (but not necessarily unix permissions)
to access app data with only per-user categories, but apps with only
per-user categories will not be able to access the data of apps with
both per-app and per-user categories.
Bug: 63897054
Test: Boot sailfish, run apps, verify no new selinux denials.
Test: cts-tradefed run cts -m CtsSelinuxTargetSdkCurrentTestCases
Test: cts-tradefed run cts -m CtsSelinuxTargetSdk27TestCases
Test: cts-tradefed run cts -m CtsSelinuxTargetSdk25TestCases
Test: adb sideload an OTA and verify that files are correctly labeled.
Change-Id: I64b013874fe87b55f47e817a1279e76ecf86b7c0
This CL creates a traceur_app domain with userdebug privileges akin to
what shell has with regards to being able to find most services on
device. Previously, traceur was running as shell which was an
unintentional abuse of selinux architecture.
Bug: 68126425
Test: Traceur functions outside of shell user privilege
Change-Id: Ib5090e7e8225ad201b3ec24b506fe2717101d0f1
This restriction causes issues with dynamite.
Since untrusted_v2_app was about enforcing this constraint put installed
v2 applications back into the normal untrusted_app domain.
Bug: 64806320
Test: Manual test with app using dynamite module
(cherrypicked from commit fe83681794)
Change-Id: I3abf3ade64aaf689039a515de642759dd39ae6f7
Don't allow apps to run with uid=shell or selinux domain=shell unless
the package is com.android.shell.
Add a neverallow assertion (compile time assertion + CTS test) to ensure
no regressions.
Bug: 68032516
Test: policy compiles, device boots, and no obvious problems.
Change-Id: Ic6600fa5608bfbdd41ff53840d904f97d17d6731
MediaProvider requires permissions that diverge from those
of a typical priv_app. This create a new domain and removes
Mtp related permissions from priv_app.
Bug: 33574909
Test: Connect with MTP, download apps and files, select ringtones
Test: DownloadProvider instrument tests, CtsProviderTestCases
Change-Id: I950dc11f21048c34af639cb3ab81873d2a6730a9
untrusted_v2_app is basically a refinement of untrusted_app with legacy
capabilities removed and potentially backwards incompatible changes.
This is not currently hooked up to anything.
Bug: 33350220
Test: builds
Change-Id: Ic9fad57476bc2b6022b1eaca8667bf6d844753c2
Motivation:
Provide the ability to phase in new security policies by
applying them to apps with a minimum targetSdkVersion.
Place untrusted apps with targetSdkVersion<=25 into the
untrustd_app_25 domain. Apps with targetSdkVersion>=26 are placed
into the untrusted_app domain. Common rules are included in the
untrusted_app_all attribute. Apps with a more recent targetSdkVersion
are granted fewer permissions.
Test: Marlin builds and boots. Apps targeting targetSdkVersion<=25
run in untrusted_app_25 domain. Apps targeting the current development
build >=26 run in the untrusted_app domain with fewer permissions. No
new denials observed during testing.
Bug: 34115651
Bug: 35323421
Change-Id: Ie6a015566fac07c44ea06c963c40793fcdc9a083
This new input selector allows phasing in new security policies by
giving app developers an opportunity to make any needed compatibility
changes before updating each app's targetSdkVersion.
When all else is equal, matching entries with higher
minTargetSdkVersion= values are preferred over entries with lower
minTargetSdkVersion= values.
Test: Marlin builds and boots. Apps targeting targetSdkVersion<=25
run in untrusted_app_25 domain. Apps targeting the current development
build >=26 run in the untrusted_app domain with fewer permissions. No
new denials observed during testing.
Bug: 34115651
Change-Id: I14bf4f51dbe26cb9bd3f62ad0b281085441d9806
The rules for the two types were the same and /data/app-ephemeral is
being removed. Remove these types.
Test: Builds
Change-Id: I520c026395551ad1362dd2ced53c601d9e6f9b28
The new domain wasn't fully tested, and it caused many regressions
on the daily build. Revert back to using "priv_app" domain until we
can fully test and re-land the new domain.
Temporarily add the USB functionfs capabilities to priv_app domain
to keep remainder of MtpService changes working; 33574909 is tracking
removing that from the priv_app domain.
Test: builds, boots, verified UI and downloads
Bug: 33569176, 33568261, 33574909
Change-Id: I1bd0561d52870df0fe488e59ae8307b89978a9cb
Also move necessary priv_app permissions into MediaProvider domain and
remove MediaProvider specific permissions from priv_app.
The new MtpServer permissions fix the following denials:
avc: denied { write } for comm=6D747020666673206F70656E name="ep0" dev="functionfs" ino=12326 scontext=u:r:priv_app:s0:c512,c768 tcontext=u:object_r:functionfs:s0 tclass=file permissive=1
denial from setting property sys.usb.ffs.mtp.ready, context priv_app
Bug: 30976142
Test: Manual, verify permissions are allowed
Change-Id: I4e66c5a8b36be21cdb726b5d00c1ec99c54a4aa4
Divide policy into public and private components. This is the first
step in splitting the policy creation for platform and non-platform
policies. The policy in the public directory will be exported for use
in non-platform policy creation. Backwards compatibility with it will
be achieved by converting the exported policy into attribute-based
policy when included as part of the non-platform policy and a mapping
file will be maintained to be included with the platform policy that
maps exported attributes of previous versions to the current platform
version.
Eventually we would like to create a clear interface between the
platform and non-platform device components so that the exported policy,
and the need for attributes is minimal. For now, almost all types and
avrules are left in public.
Test: Tested by building policy and running on device.
Change-Id: Idef796c9ec169259787c3f9d8f423edf4ce27f8c
