This patch fixes Gatekeeper HAL rules.

Bug: 34260418
Test: Device boots with gatekeeper_hal using hwbinder and
      gatekeeperd does not fall back to software.
Change-Id: I6aaacb08faaa7a90506ab569425dc525334c8171

This switches most remaining HALs to the _client/_server approach.
To unblock efforts blocked on majority of HALs having to use this
model, this change does not remove unnecessary rules from clients of
these HALs. That work will be performed in follow-up commits. This
commit only adds allow rules and thus does not break existing
functionality.

The HALs not yet on the _client/_server model after this commit are:
* Allocator HAL, because it's non-trivial to declare all apps except
  isolated apps as clients of this HAL, which they are.
* Boot HAL, because it's still on the non-attributized model and I'm
  waiting for update_engine folks to answer a couple of questions
  which will let me refactor the policy of this HAL.

Test: mmm system/sepolicy
Test: Device boots, no new denials
Test: Device boots in recovery mode, no new denials
Bug: 34170079
Change-Id: I03e6bcec2fa02f14bdf17d11f7367b62c68a14b9

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 a9ce2086.

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 f41d89eb 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
a2519226 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

Change-Id: I79a305407c3a362d7be11f4c026f31f1e9666f1c
Signed-off-by: Alexey Polyudov <apolyudov@google.com>

Addresses the following denials and auditallows:

avc: denied { read } for pid=561 comm="hwservicemanage" name="hw"
dev="dm-0" ino=1883 scontext=u:r:hwservicemanager:s0
tcontext=u:object_r:system_file:s0 tclass=dir permissive=0

avc: denied { read } for pid=748 comm="gatekeeperd" name="hw" dev="dm-0"
ino=1883 scontext=u:r:gatekeeperd:s0 tcontext=u:object_r:system_file:s0
tclass=dir permissive=0

avc: granted { read open } for pid=735 comm="fingerprintd"
path="/system/lib64/hw" dev="dm-0" ino=1883 scontext=u:r:fingerprintd:s0
tcontext=u:object_r:system_file:s0 tclass=dir

Test: no denials on boot
Change-Id: Ic363497e3ae5078e564d7195f3739a654860a32f

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

Test: builds/boots on Angler. No "granted" messages for the removed
permissions observed in three months of log audits.

Bug: 28760354
Change-Id: I0a6363f094c41392469f438c4399c93ed53fb5ac

Grant permissions observed.

Bug: 28760354
Change-Id: Ie63cda709319bbf635ef7bffbba3477c2cccc11b

Grant permissions observed.

(cherry picked from commit 9c820a11)

Merged-in: Ifdead51f873eb587556309c48fb84ff1542ae303
Bug: 28760354
Change-Id: Ifdead51f873eb587556309c48fb84ff1542ae303

Bug: 27531271
Change-Id: I3c5eee86d09696373ab155f93ba6c85da224cb51

Bug: 26945055
Change-Id: I5745d02be9889f6a0e02de12bd8d8f2808de9ce0

Motivation: Domain is overly permissive. Start removing permissions
from domain and assign them to the domain_deprecated attribute.
Domain_deprecated and domain can initially be assigned to all
domains. The goal is to not assign domain_deprecated to new domains
and to start removing domain_deprecated where it is not required or
reassigning the appropriate permissions to the inheriting domain
when necessary.

Bug: 25433265
Change-Id: I8b11cb137df7bdd382629c98d916a73fe276413c

Bug: 22257554
Change-Id: Ifaf36930bf301708c196f7bd0530abe82c1e0b50

This enables access to gatekeeperd for anybody who invokes Android
framework APIs. This is necessary because the AndroidKeyStore
abstraction offered by the framework API occasionally communicates
with gatekeeperd from the calling process.

(cherry picked from commit effcac7d)

Bug: 20526234
Change-Id: I450242cd085259b3f82f36f359ee65ff27bebd13

This enables access to gatekeeperd for anybody who invokes Android
framework APIs. This is necessary because the AndroidKeyStore
abstraction offered by the framework API occasionally communicates
with gatekeeperd from the calling process.

Bug: 20526234
Change-Id: I3362ba07d1a7e5f1c47fe7e9ba6aec5ac3fec747

Use a more specific label for /data/misc/gatekeeper

Rearrange some other rules.

Change-Id: Ib634e52526cf31a8f0a0e6d12bbf0f69dff8f6b5

Change-Id: Ia9df151cc64ad74133db2095a935220ef9f3ea8e

needs to call addAuthToken

Change-Id: If519df61448f19dfafab254668c17eea6c161ea4

The current neverallow rule (compile time assertion)

  neverallow { domain -gatekeeperd -system_server } gatekeeper_service:service_manager find;

asserts that no rule is present which allows processes other than
system_server from asking servicemanager for a gatekeeperd token.

However, if system_server leaks the token to other processes, it may
be possible for those processes to access gatekeeperd directly, bypassing
servicemanager.

Add a neverallow rule to assert that no process other than system_server
are allowed to make binder calls to gatekeeperd. Even if another process
was to manage to get a binder token to gatekeeperd, it would be useless.

Remove binder_service() from gatekeeperd. The original use of the
binder_service() macro was to widely publish a binder service.
If this macro is present and the calling process has a gatekeeperd
binder token, it's implicitly possible for the following processes
to make a binder call to gatekeeperd:

 * all app processes
 * dumpstate
 * system_server
 * mediaserver
 * surfaceflinger

Removing binder_service revokes this implicit access.

Add explicit access for system_server to make binder calls to
gatekeeperd.

Add explicit access for gatekeeperd to make calls to keystore.
This was implicitly granted via binder_service() before, but now
needs to be explicit.

Change-Id: I23c1573d04ab670a42660d5922b39eecf4265b66

Change-Id: Ie88568c43642505f68d137843a1f6b7a3de481e5

sets up:
- execute permissions
- binder permission (system_server->gatekeeper->keystore)
- prevents dumpstate and shell from finding GK binder service
- neverallow rules for prohibited clients

Change-Id: I1817933a91de625db469a20c7a4c8e2ca46efa1e