HAL clients should not be annotated with hal_x and haldomain. This may
grant them too much access. Instead, the policy needed for using
in-process HALs should be directly embedded into the client's domain
rules.
This partially reverts the moving of rules out of gatekeeperd in
commit a9ce208680.
Test: Set up PIN-protected secure lock screen, unlock screen, reboot,
unlock. No SELinux denials in gatekeeperd or hal_gatekeeper*.
Bug: 34715716
Change-Id: If87c865461580ff861e7e228a96d315d319e1765
Introduce the add_service() macro which wraps up add/find
permissions for the source domain with a neverallow preventing
others from adding it. Only a particular domain should
add a particular service.
Use the add_service() macro to automatically add a neverallow
that prevents other domains from adding the service.
mediadrmserver was adding services labeled mediaserver_service.
Drop the add permission as it should just need the find
permission.
Additionally, the macro adds the { add find } permission which
causes some existing neverallow's to assert. Adjust those
neverallow's so "self" can always find.
Test: compile and run on hikey and emulator. No new denials were
found, and all services, where applicable, seem to be running OK.
Change-Id: Ibbd2a5304edd5f8b877bc86852b0694732be993c
Signed-off-by: William Roberts <william.c.roberts@intel.com>
In my commit f41d89eb24 I forgot to
switch rild and gatekeeperd rules from explicitly associating these
domains with the hal_telephony and hal_gatekeeper to using the
hal_impl_domain macro. As a result, the recent commit
a25192262b inadvertently revoked
HwBinder access from rild and gatekeeperd.
This commit fixes the issue by switching rild and gatekeeperd to the
hal_impl_domain macro.
Test: "sepolicy-analyze out/target/product/bullhead/root/sepolicy attribute haldomain"
now lists rild and gatekeeperd
Test: "sepolicy-analyze out/target/product/bullhead/root/sepolicy attribute hal_telephony"
still lists rild
Test: "sepolicy-analyze out/target/product/bullhead/root/sepolicy attribute hal_gatekeeper"
still lists gatekeeperd
Bug: 34180936
Bug: 34470443
Change-Id: I7949556f58c36811205d5ea3ee78ea5708e95b45
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
