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>
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
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
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
snapshotctl is a shell interface for libsnapshot. After rebooting
into an updated build, on sys.boot_completed, init calls
snapshotctl to merge snapshots. In order to do that, it needs to:
- Talk to gsid to mount and unmount COW images
- read the current slot suffix to do checks (and avoid merging
snapshots when it shouldn't).
- read / write OTA metadata files to understand states of
the snapshot
- delete OTA metadata files once a snapshot is merged
- collapse the snapshot device-mapper targets into a plain
dm-linear target by re-mapping devices on device-mapper
Test: reboot after OTA, see merge completed without denials
Bug: 135752105
Change-Id: Idfe99d4004e24805d56cd0ab2479557f237c2448
PathForModuleInstall now returns an InstallPath and supports an
InstallInRoot method to install into $OUT/recovery/root.
Bug: 141877526
Test: m checkbuild
Change-Id: I2c63024336e195e772171a24cb8d2a5b61663e61
Ashmem FD selinux labels have recently been changed (aosp/1127917) from
"ashmemd" to the label of the whichever process opens the fd, which
resulted in the following denial:
avc: denied { use } for
path="/dev/ashmemf5dc2dbf-d1e7-457e-b694-93c84704135e" dev="tmpfs"
ino=18972 ioctlcmd=0x7704 scontext=u:r:zygote:s0
tcontext=u:r:system_server:s0 tclass=fd permissive=1
Test: m selinux_policy
Change-Id: I4880420014bda21cd4f83e3d6190c3cfaa76822f
update_engine tries to determine the parent path for all devices (e.g.
/dev/block/by-name) by reading the default fstab and looking for the misc
device. ReadDefaultFstab() checks whether a GSI is running by checking
gsi_metadata_file. We never apply OTAs when GSI is running, so just deny
the access.
Test: no selinux denials
Fixes: 139283697
Change-Id: I3cba28ccb6871b328ab697a4a8f3476ac72f7bed
- /data/gsi/ota/* now has the type ota_image_data_file. At runtime
during an OTA, update_engine uses libsnapshot to talk to gsid
to create these images as a backing storage of snapshots. These
"COW images" stores the changes update_engine has applied to
the partitions.
If the update is successful, these changes will be merged to the
partitions, and these images will be teared down. If the update
fails, these images will be deleted after rolling back to the
previous slot.
- /metadata/gsi/ota/* now has the type ota_metadata_file. At runtime
during an OTA, update_engine and gsid stores update states and
information of the created snapshots there. At next boot, init
reads these files to re-create the snapshots.
Beside these assignments, this CL also allows gsid and update_engine
to have the these permissions to do these operations.
Bug: 135752105
Test: apply OTA, no failure
Change-Id: Ibd53cacb6b4ee569c33cffbc18b1b801b62265de
The wifi stack APK will run inside the network_stack process. So, move
the sepolicy rules for wifi stack inside the network stack rules.
Bug: 135691051
Test: Manual tests
- manual connect to wifi networks
- Remove networks
Test: Will send for ACTS wifi regression testing
Change-Id: I9d5da80852f22fa1d12b2dbbc76b9e06c1275310
(cherry-picked from b83abf7af3df64e0d3c1b22548f2344b55aece28)
Vendors can publish services with servicemanager only on non-Treble
builds. vendor_service_contexts is not meant to be read by
servicemanager.
5bccbfefe4/public/servicemanager.te (22)
Bug: 141333155
Test: create /vendor/etc/selinux/vendor_service_contexts and make sure it is
correctly labeled.
Change-Id: Ib68c50e0cdb2c39f0857a10289bfa26fa11b1b3c
dumpstate need to access /proc/pressure/{cpu,mem,io}
Bug: 141884936
Test: adb bugreport and check bugreport file includes PSI metric
Change-Id: I01e7376206c07c1700d6ffe3690d61a1db8dfe84
Signed-off-by: Minchan Kim <minchan@google.com>
The commit 7baf725ea6 broke OMX on O/O-MR1(/P?) vendors.
Previous to this commit, all OMX codecs had to use "mediacodec" type,
after this commit, omx codecs just had to get hal_omx_server attribute.
This commit left to the vendor the charge of adding "hal_omx_server"
attribute to mediacodec.
However this can't work on non-Q vendors.
On P vendor, versioned_plat_pub contains the appdomain <=> mediacodec
allows, so OMX isn't technically broken on those devices.
But to ensure it won't break in the future, mark 28's mediacodec as
hal_omx_server as well
This fixes broken OMX decoding on O/O-MR1 vendors, failing with the
following denial:
avc: denied { call } for comm=4E444B204D65646961436F6465635F scontext=u:r:platform_app:s0:c512,c768 tcontext=u:r:mediacodec:s0 tclass=binder permissive=0
Bug: 141186440
Change-Id: I018f8d9aabc77e7ea86ca14734b1ab2edfdf8ed1
Introduces new domain vendor_boringssl_self_test and runs
/vendor/bin/boringssl_self_test(32|64) in it. New domain
required because boringssl_self_test needs to be in
coredomain in order to reboot the device, but vendor code
may not run in coredomain.
Bug: 141150335
Test: flashall && manually verify no selinux errors logged and that
four flag files are created in /dev/boringssl, two by the
system self tests and two by the vendor.
Change-Id: I46e2a5ea338eddacdfd089f696295dbd16795c5a
Allow vendor-init to set the new property ro.crypto.volume.flags so that
vendors can configure file-based encryption on adoptable storage to use
v2 encryption policies. This is analogous to the existing properties
ro.crypto.volume.contents_mode and ro.crypto.volume.filenames_mode.
Bug: 140500999
Test: see If64028d8580584b2c33c614cabd5d6b93657f608
Change-Id: Ibde73e0556b6a08e2653149c1cdbf39cdcae6112
Also add neverallow rules to enforce that unintended domains aren't
allowed to use any of the fscrypt ioctls.
(Originally based on a patch by Satya Tangirala <satyat@google.com>)
Bug: 140500828
Test: see I296ef78138578a3fd773797ac0cd46af1296b959
Change-Id: I01e81edf0d948af254ddf4275702e7224b2698e4
![](/avatar/ef4a85532a29218c6b19b60e782b0746?size=56 "Harpreet \\"Eli\\" Sangha"){kind=small}
