The credstore service is a system service which backs the
android.security.identity.* Framework APIs. It essentially calls into
the Identity Credential HAL while providing persistent storage for
credentials.
Bug: 111446262
Test: atest android.security.identity.cts
Test: VtsHalIdentityTargetTest
Test: android.hardware.identity-support-lib-test
Change-Id: I5cd9a6ae810e764326355c0842e88c490f214c60
Before this change, access to HALs from untrusted apps was prohibited
except for the whitelisted ones like the gralloc HAL, the renderscript
HAL, etc. As a result, any HAL that is added by partners can't be
accessed from apps. This sometimes is a big restriction for them when
they want to access their own HALs in the same-process HALs running in
apps. Although this is a vendor-to-vendor communication and thus is not
a Treble violation, that was not allowed because their HALs are not in
the whitelist in AOSP.
This change fixes the problem by doing the access control in the
opposite way; access to HALs are restricted only for the blacklisted
ones.
All the hwservice context that were not in the whitelist are now put
to blacklist.
This change also removes the neverallow rule for the binder access to
the halserverdomain types. This is not needed as the protected
hwservices living in the HAL processes are already not accessible; we
have a neverallow rule for preventing hwservice_manager from finding
those protected hwservices from untrusted apps.
Bug: 139645938
Test: m
Merged-In: I1e63c11143f56217eeec05e2288ae7c91e5fe585
(cherry picked from commit 580375c923)
Change-Id: I4e611091a315ca90e3c181f77dd6a5f61d3a6468
Before this change, access to HALs from untrusted apps was prohibited
except for the whitelisted ones like the gralloc HAL, the renderscript
HAL, etc. As a result, any HAL that is added by partners can't be
accessed from apps. This sometimes is a big restriction for them when
they want to access their own HALs in the same-process HALs running in
apps. Although this is a vendor-to-vendor communication and thus is not
a Treble violation, that was not allowed because their HALs are not in
the whitelist in AOSP.
This change fixes the problem by doing the access control in the
opposite way; access to HALs are restricted only for the blacklisted
ones.
All the hwservice context that were not in the whitelist are now put
to blacklist.
This change also removes the neverallow rule for the binder access to
the halserverdomain types. This is not needed as the protected
hwservices living in the HAL processes are already not accessible; we
have a neverallow rule for preventing hwservice_manager from finding
those protected hwservices from untrusted apps.
Bug: 139645938
Test: m
Change-Id: I1e63c11143f56217eeec05e2288ae7c91e5fe585
This is unused currently & there are no concrete plans to use it
in the future.
Bug: 130080335
Test: Device boots up & connects to networks.
Test: Will send for regression tests
Change-Id: I785389bc2c934c8792c8f631362d6aa0298007af
Add the required permissions for the InputClassifier HAL.
Bug: 62940136
Test: no selinux denials in logcat when HAL is used inside input flinger.
Change-Id: Ibc9b115a83719421d56ecb4bca2fd196ec71fd76
Notes:
- Added face hal domain, context and file types for the default
SELinux policy.
- Please see aosp/q/topic:"Face+Authentication"
Bug: 80155388
Test: Built successfully.
Change-Id: I2e02cf6df009c5ca476dfd842b493c6b76b7712a
Add a neverallow rule asserting that services registered or queried
through hwservicemanager must have the attribute hwservice_manager_type.
Attempting to add or query a service which does not have that
attribute is malformed policy.
Test: compiles
Change-Id: Ib498508694f478c396f2d9273abaccbff06975e6
Also giving statsd permission to access it. This change copies the internal sepolicy to AOSP.
Bug: 111185513
Bug: 120551881
Test: make
Change-Id: I7e0386777e05580299caf9b97cb7804459f1a9d0
Bug: 116732452
Test: No sepolicy violations observed with this change
(cherry picked from commit I1958182dd8ecc496625da2a2a834f71f5d43e7bb)
Change-Id: Ib386767d8acfacf9fedafd9a79dd555ce233f41c
...to reflect that the HAL operates on storage devices,
not filesystem.
Bug: 111655771
Test: compiles
Change-Id: Ibb0572cb1878359e5944aa6711331f0c7993ba6e
Merged-In: Ibb0572cb1878359e5944aa6711331f0c7993ba6e
...to reflect that the HAL operates on storage devices,
not filesystem.
Bug: 111655771
Test: compiles
Change-Id: Ibb0572cb1878359e5944aa6711331f0c7993ba6e
This hwservice isn't registered with hwservicemanager but rather passed
to the thermal hal, so it doesn't need sepolicy associated with it to
do so.
Test: manual: boot, inspect logs
Test: VtsHalThermalV1_1TargetTest
Bug: 109802374
Change-Id: Ifb727572bf8eebddc58deba6c0ce513008e01861
Merged-In: Ifb727572bf8eebddc58deba6c0ce513008e01861
* Note on cherry-pick: Some of the dependent changes are not in AOSP.
In order to keep hostapd running correctly in AOSP, I've modified this
change to only include policy additions.
Change sepolicy permissions to now classify hostapd as a HAL exposing
HIDL interface.
Sepolicy denial for accessing /data/vendor/misc/wifi/hostapd:
12-27 23:40:55.913 4952 4952 W hostapd : type=1400 audit(0.0:19): avc:
denied { write } for name="hostapd" dev="sda13" ino=4587601
scontext=u:r:hal_wifi_hostapd_default:s0
tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
01-02 19:07:16.938 5791 5791 W hostapd : type=1400 audit(0.0:31): avc:
denied { search } for name="net" dev="sysfs" ino=30521
scontext=u:r:hal_wifi_hostapd_default:s0
tcontext=u:object_r:sysfs_net:s0 tclass=dir permissive=0
Bug: 36646171
Test: Device boots up and able to turn on SoftAp.
Change-Id: Ibacfcc938deab40096b54b8d0e608d53ca91b947
Merged-In: Ibacfcc938deab40096b54b8d0e608d53ca91b947
(cherry picked from commit 5bca3e860d)
