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
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
SELinux has a separate file mmap permission in 4.14+ kernels. Add this
to profman in cases where it could already access files.
Bug: 112990132
Test: atest com.android.cts.dexmetadata.InstallDexMetadataHostTest
Change-Id: I4f3cd55fbd4d0052500f07aac7d286c397758abc
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
When opening the dex files we sometime need to check for the real location
of the file (even if it was open via an fd).
Denial example:
avc: denied { getattr } for comm="profman" path="/data/app" dev="sda13"
ino=1048577 scontext=u:r:profman:s0 tcontext=u:object_r:apk_data_file:s0
tclass=dir permissive=0
Test: verify we get no denials when taking a profile snapshot.
Bug: 77922323
(cherry picked from commit 9e80bfc880)
Change-Id: I934170a67640bb8534c123848468c0861b245eeb
The secondary dex files are application dex files which gets reported
back to the framework when using BaseDexClassLoader.
Also, give dex2oat lock permissions as it needs to lock the profile
during compilation.
Example of SElinux denial:
03-15 12:38:46.967 7529 7529 I profman : type=1400 audit(0.0:225):
avc: denied { read } for
path="/data/data/com.google.android.googlequicksearchbox/files/velour/verified_jars/JDM5LaUbYP1JPOLzJ81GLzg_1.jar.prof"
dev="sda35" ino=877915 scontext=u:r:profman:s0
tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file permissive=1
Test: adb shell cmd package bg-dexopt-job works for sercondary dex files
Bug: 26719109
Change-Id: Ie1890d8e36c062450bd6c54f4399fc0730767dbf
Since it was introduced it caused quite a few issues and it spams the
SElinux logs unnecessary.
The end goal of the audit was to whitelist the access to the
interpreter. However that's unfeasible for now given the complexity.
Test: devices boots and everything works as expected
no more auditallow logs
Bug: 29795519
Bug: 32871170
Change-Id: I9a7a65835e1e1d3f81be635bed2a3acf75a264f6
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
