ART is becoming a module and we need to be able to add new properties
without modifying the non updatable part of the platform:
- convert ART properties to use prefix in the namespace of
[ro].dalvik.vm.
- enable appdomain and coredomain to read device_config properties
that configure ART
Test: boot
Bug: 181748174
Change-Id: Id23ff78474dba947301e1b6243a112b0f5b4a832
ART runtime will be using userfaultfd for a new heap compaction
algorithm. After enabling userfaultfd in android kernels (with SELinux
support), the feature needs policy that allows { create ioctl read }
operations on userfaultfd file descriptors.
Bug: 160737021
Test: Manually tested by exercising userfaultfd ops in ART
Change-Id: I9ccb7fa9c25f91915639302715f6197d42ef988e
odsign exec()'s odrefresh, which in turn exec()'s dexoptanalyzer.
Bug: 165630556
Test: No denials on boot
Change-Id: Ie97726cfbdbf09f75fa0b00d34ee10c9bdf5a5d7
odrefresh is the process responsible for checking and creating ART
compilation artifacts that live in the ART APEX data
directory (/data/misc/apexdata/com.android.art).
There are two types of change here:
1) enabling odrefresh to run dex2oat and write updated boot class path
and system server AOT artifacts into the ART APEX data directory.
2) enabling the zygote and assorted diagnostic tools to use the
updated AOT artifacts.
odrefresh uses two file contexts: apex_art_data_file and
apex_art_staging_data_file. When odrefresh invokes dex2oat, the
generated files have the apex_art_staging_data_file label (which allows
writing). odrefresh then moves these files from the staging area to
their installation area and gives them the apex_art_data_file label.
Bug: 160683548
Test: adb root && adb shell /apex/com.android.art/bin/odrefresh
Change-Id: I9fa290e0c9c1b7b82be4dacb9f2f8cb8c11e4895
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
dexoptanalyzer need read access on the secondary
dex files and of the main apk files in order to successfully evaluate
and optimize them.
Example of denial:
audit(0.0:30): avc: denied { read } for
path="/data/app/~~Zux_isdY0NBkRWPp01oAVg==/com.example.secondaryrepro-wH9zezMSCzIjcKdIMtrw7A==/base.apk"
dev="vdc" ino=40966 scontext=u:r:dexoptanalyzer:s0
tcontext=u:object_r:apk_data_file:s0 tclass=file permissive=0
app=com.example.secondaryrepro
Test: adb shell cmd package compile -r bg-dexopt --secondary-dex app
Bug: 160471235
Bug: 160351055
Change-Id: Id0bda5237d3ce1620d4f6ee89595836b4e1f3abf
SELinux has a separate file mmap permission in 4.14+ kernels. Add this
to dexoptanalyzer(d) in cases where it could already access files (in
particular, secondary dex files).
Addresses denials of the form:
avc: denied { map } for […] path="/data/data/[…]" […]
scontext=u:r:dexoptanalyzer:s0 tcontext=u:object_r:app_data_file:s0
Test: Reproduce steps in bug 138683603 on a device with a 4.14+ kernel
and check the absence of SELinux denials
Bug: 138683603
Change-Id: Ieba53eb431c0ba3914dcb5e5abdae667bd063555
Allow dexoptanalyzer(d) to lock `system_file` files, so that it can
lock `/system/framework/$ISA/*.art` files (which is harmless as these
files live in a read-only partition, but admittedly simplifies the
corresponding logic in ART).
Addresses denials of the form:
avc: denied { lock } for path="/system/framework/arm/boot.art"
dev="dm-0" ino=1330 scontext=u:r:dexoptanalyzer:s0
tcontext=u:object_r:system_file:s0 tclass=file permissive=0 […]
Test: Reproduce steps in bug 138683603 and check the absence of SELinux denials
Bug: 138683603
Change-Id: I8a08822b4908b3b37bd0e450dd1356ed92332327
Dexoptanalyzer is getting a new mode to instruct installd on which dex
files it needs to open for itself and dex2oat from class loader context.
The file list is communicated by a pipe from a forked dexoptanalyzer
process to the installd parent. Give dexoptanalyzer permission to write
to installd's pipes.
Bug; 126674985
Test: atest installd_dexopt_test
Change-Id: Ic415e2dc543099d26681103c9d368c941d21b49a
This is being done in preparation for the migration from ashmem to
memfd. In order for tmpfs objects to be usable across the Treble
boundary, they need to be declared in public policy whereas, they're
currently all declared in private policy as part of the
tmpfs_domain() macro. Remove the type declaration from the
macro, and remove tmpfs_domain() from the init_daemon_domain() macro
to avoid having to declare the *_tmpfs types for all init launched
domains. tmpfs is mostly used by apps and the media frameworks.
Bug: 122854450
Test: Boot Taimen and blueline. Watch videos, make phone calls, browse
internet, send text, install angry birds...play angry birds, keep
playing angry birds...
Change-Id: I20a47d2bb22e61b16187015c7bc7ca10accf6358
Merged-In: I20a47d2bb22e61b16187015c7bc7ca10accf6358
(cherry picked from commit e16fb9109c)
system_file_type is a new attribute used to identify files which exist
on the /system partition. It's useful for allow rules in init, which are
based off of a blacklist of writable files. Additionally, it's useful
for constructing neverallow rules to prevent regressions.
Additionally, add commented out tests which enforce that all files on
the /system partition have the system_file_type attribute. These tests
will be uncommented in a future change after all the device-specific
policies are cleaned up.
Test: Device boots and no obvious problems.
Change-Id: Id9bae6625f042594c8eba74ca712abb09702c1e5
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.
This change adds a new file type "privapp_data_file". For compatibility,
we adjust the policy to support access privapp_data_files almost
everywhere we were previously granting access to app_data_files
(adbd and run-as being exceptions). Additional future tightening is
possible here by removing some of these newly added rules.
This label will start getting used in a followup change to
system/sepolicy/private/seapp_contexts, similar to:
-user=_app isPrivApp=true domain=priv_app type=app_data_file levelFrom=user
+user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user
For now, this newly introduced label has no usage, so this change
is essentially a no-op.
Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
filesystem upgrade.
Change-Id: I9618b7d91d1c2bcb5837cdabc949f0cf741a2837
A legitimate call to access(2) is generating a denial. Use the
audit_access permission to suppress the denial on just the access()
call.
avc: denied { write } for name="verified_jars"
scontext=u:r:dexoptanalyzer:s0
tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir
Bug: 62597207
Test: build policy
Test: The following cmd succeeds but no longer generates a denial
adb shell cmd package compile -r bg-dexopt --secondary-dex \
com.google.android.googlequicksearchbox
Change-Id: I7d03df2754c24c039bce11426bf8f317232f5e5f
(cherry picked from commit 575e627081)
On PRODUCT_FULL_TREBLE devices, non-vendor domains (except vendor
apps) are not permitted to use Binder. This commit thus:
* groups non-vendor domains using the new "coredomain" attribute,
* adds neverallow rules restricting Binder use to coredomain and
appdomain only, and
* temporarily exempts the domains which are currently violating this
rule from this restriction. These domains are grouped using the new
"binder_in_vendor_violators" attribute. The attribute is needed
because the types corresponding to violators are not exposed to the
public policy where the neverallow rules are.
Test: mmm system/sepolicy
Test: Device boots, no new denials
Test: In Chrome, navigate to ip6.me, play a YouTube video
Test: YouTube: play a video
Test: Netflix: play a movie
Test: Google Camera: take a photo, take an HDR+ photo, record video with
sound, record slow motion video with sound. Confirm videos play
back fine and with sound.
Bug: 35870313
Change-Id: I0cd1a80b60bcbde358ce0f7a47b90f4435a45c95
This CLs adds SElinux policies necessary to compile secondary dex files.
When an app loads secondary dex files via the base class loader the
files will get reported to PM. During maintance mode PM will compile the
secondary dex files which were used via the standard installd model
(fork, exec, change uid and lower capabilities).
What is needed:
dexoptanalyzer - needs to read the dex file and the boot image in order
to decide if we need to actually comppile.
dex2oat - needs to be able to create *.oat files next to the secondary
dex files.
Test: devices boots
compilation of secondary dex files works without selinux denials
cmd package compile --secondary-dex -f -m speed
com.google.android.gms
Bug: 32871170
Change-Id: I038955b5bc9a72d49f6c24c1cb76276e0f53dc45
