A new sysprop neverallow rules are mandatory only for devices launching
with R or later. For devices already launched, neverallow rules can be
relaxed with adding following line to BoardConfig.mk:
BUILD_BROKEN_TREBLE_SYSPROP_NEVERALLOW := true
Bug: 131162102
Test: Set PRODUCT_SHIPPING_API_LEVEL := 30 and try building with
changing some system_public_prop to system_internal_prop
Test: m cts sepolicy_tests
Change-Id: Id978b4d81a8683a57304bb639961105e2d91fa9a
Merged-In: Id978b4d81a8683a57304bb639961105e2d91fa9a
(cherry picked from commit 3be11e7abb)
This property is used for testing purposes when verifying the
behavior when an OTA occurs. It should be readable by the
system server, and be settable by the shell.
Test: Set property from shell, read with PackageManager
Bug: 140992644
Change-Id: I39ad9b7961208f02fa45011215c2ff5ac03b7380
This CL addresses the following denial, when vendor_misc_writer tries to
read DT fstab (i.e. device tree fstab) for /misc entry.
avc: denied { search } for comm="misc_writer" name="android" dev="sysfs" ino=17456 scontext=u:r:vendor_misc_writer:s0 tcontext=u:object_r:sysfs_dt_firmware_android:s0 tclass=dir
DT fstab was used for devices shipped prior to Q, for early-mounting
partitions (e.g. /system, /vendor, /product), which has been disallowed
for Q launch devices. vendor_misc_writer is a new module added since Q,
so it doesn't need to worry about the legacy code path; in practice
there's no benefit of putting /misc entry into DT fstab either.
Bug: 134122603
Test: Build and flash taimen with the change that enables
vendor_misc_writer. Check that it no longer gives the above denial
during boot.
Change-Id: Id2fb206706f7cd19a4cde2701e4155bfc03f01b4
Newly added ro.lmk.psi_partial_stall_ms, ro.lmk.psi_complete_stall_ms,
ro.lmk.thrashing_limit and ro.lmk.thrashing_limit_decay should be
configurable by vendors.
Bug: 132642304
Change-Id: Ifd3513c78e75d77be8d7c3594bef48ea27cc80b3
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
This is needed to get Java heap graphs.
Test: flash aosp; profile system_server with setenforce 1
Bug: 136210868
Change-Id: I87dffdf28d09e6ce5f706782422510c615521ab3
APEX modules can be configured with apex_name and file_contexts
properties.
- apex_name overrides the activation point
for example, if apex_name is 'foo', it will be flattened under
/system/apex/foo even if its name is 'bar'.
- file_contexts overrides file_contexts filename
for example, it file_contexts is 'foo',
/system/sepolicy/apex/foo-file_contexts should be used even if its
name is 'bar'.
Previously, file_contexts files for flattened apexes are assumed to have
names like "/system/sepolicy/apex/<apex_name>-file_contexts". But, as
described above, calculating <apex_name> from file entries might be
wrong
Now, it relies on Soong's makevar APEX_FILE_CONTEXTS_INFOS which is list of
<apex_name>:<file_contexts> pairs.
Bug: 123314817
Bug: 142300241
Test: add apex module(foo) with apex_name:bar and file_contexts:baz
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m file_contexts.bin
Test: check intermediate files for file_contexts
Change-Id: I3793c0f01469baaa0ddb1965093a56304a10e99c
zygote now allocates JIT memory using libcutils API (aosp/1135101)
instead of going to /dev/ashmem directly, which requires execute
permissions to ashmem_libcutils_device.
Bug: 134434505
Test: boot crosshatch
Change-Id: I0a54d64bd4656fafd2f03701d7828cfa94c08f04
https://boringssl-review.googlesource.com/c/boringssl/+/38024 will
introduce a feature allowing vendors finer grained control over
BoringSSL's random source by setting a system property.
The property needs to be settable from vendor init and readable by all
processes on the device.
As BoringSSL will be in a mainline module, we need to provide a
non-source code way of allowing vendor customisations.
Bug: 142129238
Test: Observe property is settable from /vendor/default.prop and
readable by non-root, non-vendor processes.
Change-Id: I4c20349f1b2ab2f51ac11ec552b99b1e15b14dd8
Only allow apps targetting < Q and ephemeral apps to open /dev/ashmem.
Ephemeral apps are not distinguishable based on target API. So allow
ephemeral_app to open /dev/ashmem for compatibility reasons.
For sake of simplicity, allow all domains /dev/ashmem permissions other
than "open". Reason being that once we can remove "open" access
everywhere, we can remove the device altogether along with other
permission.
Bug: 134434505
Test: boot crosshatch; browse internet, take picture;
no ashmem_device denials
Change-Id: Ib4dddc47fcafb2697795538cdf055f305fa77799
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This change includes the sepolicy changes to move the recovery resources from
system to vendor. The big change is renaming install_recovery*.te to
vendor_install_recovery*.te to emphasize the move to vendor. Other changes
follow from that. The net result is that the application of the recovery patch
has the same permissions that it had when it lived in system.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: If29cb22b2a7a5ce1b25d45ef8635e6cb81103327
Android.mk now includes the SELinux denial metadata on user builds.
Bug: 141695494
Test: Generated a tracked denial on a user build and verified that the
bug number shows up in the logs.
Change-Id: I908c08e0d6542fa248d7c798c20a66027f39c390
Some targets just need to extend product context files, e.g.,
file_contexts, service_contexts, etc., without adding any
product-specific policy files, e.g., *.te files. Or just need to
add private product sepolicy without adding public product sepolicy.
Currently, this will lead to build errors. This CL allows
product_sepolicy.cil and the product mapping file to be empty.
It's now also possible to just set PRODUCT_PRIVATE_POLICY
without setting PRODUCT_PUBLIC_POLICY.
Bug: 131193755
Test: Only adds product private sepolicy, then `mmma system/sepolicy`
Change-Id: Ifed5af7413b2a1e20a0628518582615708c8c31a
Some targets just need to extend system_ext context files, e.g.,
file_contexts, service_contexts, etc., without adding any system_ext
policy files, e.g., *.te files.
Currently, this will lead to build errors. This CL allows
system_ext_sepolicy.cil and the system_ext mapping file
to be empty.
It's now also possible to just set BOARD_PLAT_PRIVATE_SEPOLICY_DIR
without setting BOARD_PLAT_PUBLIC_SEPOLICY_DIR.
Bug: 137712473
Bug: 141880898
Test: Only adds system_ext context files without policy files (e.g., *.te),
then `mmma system/sepolicy` can build pass
Change-Id: I72849f2d4aa43e5296cd15c07a8fd058186a6376
Probably flew under the radar because Google only tests on devices that
include devices with a physical /vendor partition.
Test: "make selinux_policy", confirm correct labels on a legacy device
Change-Id: I1aa856c6e3774912d1f4c0a09bbc2d174016f59d
Signed-off-by: Felix <google@ix5.org>
![](/avatar/ef4a85532a29218c6b19b60e782b0746?size=56 "Harpreet \\"Eli\\" Sangha"){kind=small}
