Vendor boot hal, init, and vold processes all require permission.
Test: build and boot aosp_cf_x86_64_phone
Bug: 173815685
Change-Id: I15692dcd39dfc9c3a3b7d8c12d03eff0a7c96f72
VtsHalBootV1_0Target test cases fail on a platform when executing boot control operation.
The cases fail because of hal_bootctl has no sys_rawio permission to do storage IOCTL to
switch boot slot.
Bug: 118011561
Test: VtsHalBootV1_0Target can pass
Change-Id: Idbbb9ea8b76fe62b2d4b71356cef7a07ad4de890
commit 9b2e0cbeea added a new
self:global_capability_class_set macro that covers both self:capability
and self:cap_userns. Apply the new macro to various self:capability
references that have cropped up since then.
Bug: 112307595
Test: policy diff shows new rules are all cap_userns
Change-Id: I3eb38ef07532a8e693fd549dfdbc4a6df5329609
Since this attribute just associates a hal_attribute
with a given hwservice in the standard way.
Bug: 80319537
Test: boot + sanity + test for denials
Change-Id: I545de165515387317e6920ce8f5e8c491f9ab24e
For sanity, this makes 'hal_attribute_hwservice_client'
be associated with a specific hwservice thus making things
consistent.
After this change, only configstore, hal_allocator, and the
fwk_* services are inconsistent with all other HALs.
Bug: 80319537
Test: boot device, sanity tests, check for denials
Change-Id: Ibffc65c9567a429e07a3dc4dd41117738459dc2a
Before, it was possible to access a hwservice without declaring
that you were a client.
This introduces the following macro:
hal_attribute_hwservice_client(hal_foo, hal_foo_hwservice)
which makes sure the above implication holds using a neverallow rule.
Bug: 80319537
Test: boot + sanity
Change-Id: Iededae68f14f0f3bd412c1205aa3b650a54d55c6
We often see the following denials:
avc: denied { sys_rawio } for comm="update_engine" capability=17 scontext=u:r:update_engine:s0 tcontext=u:r:update_engine:s0 tclass=capability permissive=0
avc: denied { sys_rawio } for comm="boot@1.0-servic" capability=17 scontext=u:r:hal_bootctl_default:s0 tcontext=u:r:hal_bootctl_default:s0 tclass=capability permissive=0
These are benign, so we are hiding them.
Bug: 37778617
Test: Boot device.
Change-Id: Iac196653933d79aa9cdeef7670076f0efc97b44a
This adds fine-grained policy about who can register and find which
HwBinder services in hwservicemanager.
Test: Play movie in Netflix and Google Play Movies
Test: Play video in YouTube app and YouTube web page
Test: In Google Camera app, take photo (HDR+ and conventional),
record video (slow motion and normal), and check that photos
look fine and videos play back with sound.
Test: Cast screen to a Google Cast device
Test: Get location fix in Google Maps
Test: Make and receive a phone call, check that sound works both ways
and that disconnecting the call frome either end works fine.
Test: Run RsHelloCompute RenderScript demo app
Test: Run fast subset of media CTS tests:
make and install CtsMediaTestCases.apk
adb shell am instrument -e size small \
-w 'android.media.cts/android.support.test.runner.AndroidJUnitRunner'
Test: Play music using Google Play music
Test: Adjust screen brightness via the slider in Quick Settings
Test: adb bugreport
Test: Enroll in fingerprint screen unlock, unlock screen using
fingerprint
Test: Apply OTA update:
Make some visible change, e.g., rename Settings app.
make otatools && \
make dist
Ensure device has network connectivity
ota_call.py -s <serial here> --file out/dist/sailfish-ota-*.zip
Confirm the change is now live on the device
Bug: 34454312
(cherry picked from commit 632bc494f1)
Merged-In: Iecf74000e6c68f01299667486f3c767912c076d3
Change-Id: I7a9a487beaf6f30c52ce08e04d415624da49dd31
This switches Boot Control HAL policy to the design which enables us
to conditionally remove unnecessary rules from domains which are
clients of Boot Control HAL.
Domains which are clients of Boot Control HAL, such as update_server,
are granted rules targeting hal_bootctl only when the Boot Control HAL
runs in passthrough mode (i.e., inside the client's process). When the
HAL runs in binderized mode (i.e., in another process/domain, with
clients talking to the HAL over HwBinder IPC), rules targeting
hal_bootctl are not granted to client domains.
Domains which offer a binderized implementation of Boot Control HAL,
such as hal_bootctl_default domain, are always granted rules targeting
hal_bootctl.
P. S. This commit removes direct access to Boot Control HAL from
system_server because system_server is not a client of this HAL. This
commit also removes bootctrl_block_device type which is no longer
used. Finally, boot_control_hal attribute is removed because it is now
covered by the hal_bootctl attribute.
Test: Device boots up, no new denials
Test: Reboot into recovery, sideload OTA update succeeds
Test: Apply OTA update via update_engine:
1. make dist
2. Ensure device has network connectivity
3. ota_call.py -s <serial here> out/dist/sailfish-ota-*.zip
Bug: 34170079
Change-Id: I9c410c092069e431a3852b66c04c4d2a9f1a25cf
