As a result, Keymaster and DRM HALs are permitted to talk to tee domain
over sockets. Unfortunately, the tee domain needs to remain on the
exemptions list because drmserver, mediaserver, and surfaceflinger are
currently permitted to talk to this domain over sockets.

We need to figure out why global policy even defines a TEE domain...

Test: mmm system/sepolicy
Bug: 36601092
Bug: 36601602
Bug: 36714625
Bug: 36715266
Change-Id: I0b95e23361204bd046ae5ad22f9f953c810c1895

On PRODUCT_FULL_TREBLE devices, non-vendor domains (coredomain) and
vendor domain are not permitted to connect to each other's sockets.
There are two main exceptions: (1) apps are permitted to talk to other
apps over Unix domain sockets (this is public API in Android
framework), and (2) domains with network access (netdomain) are
permitted to connect to netd.

This commit thus:
* adds neverallow rules restricting socket connection establishment,
* temporarily exempts the domains which are currently violating this
  rule from this restriction. These domains are grouped using the new
  "socket_between_core_and_vendor_violators" attribute. The attribute
  is needed because the types corresponding to violators are not
  exposed to the public policy where the neverallow rules are.

Test: mmm system/sepolicy
Bug: 36613996
Change-Id: I458f5a09a964b06ad2bddb52538ec3a15758b003

This switches Keymaster HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of Keymaster HAL.

Domains which are clients of Keymaster HAL, such as keystore and vold
domains, are granted rules targeting hal_keymaster only when the
Keymaster 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_keymaster are not granted to client domains.

Domains which offer a binderized implementation of Keymaster HAL, such
as hal_keymaster_default domain, are always granted rules targeting
hal_keymaster.

Test: Password-protected sailfish boots up and lock screen unlocks --
      this exercises vold -> Keymaster HAL interaction
Test: All Android Keystore CTS tests pass -- this exercises keystore ->
      Keymaster HAL interaction:
      make cts cts-tradefed
      cts-tradefed run singleCommand cts --skip-device-info \
      --skip-preconditions --skip-connectivity-check --abi arm64-v8a \
      --module CtsKeystoreTestCases
Bug: 34170079

Change-Id: I2254d0fdee72145721654d6c9e6e8d3331920ec7

hal_*_default daemons whose policy is in common/device-agnostic policy
are provided by the vendor image (see vendor/file_contexts). Thus,
their policy should also reside in the vendor image, rather than in
the system image. This means their policy should live in the vendor
subdirectory of this project.

Test: Device boots and appears to work
Bug: 34135607
Bug: 34170079
Change-Id: I6613e43733e03d4a3d4726f849732d903e024016

This adds the premissions required for
android.hardware.keymaster@2.0-service to access the keymaster TA
as well as for keystore and vold to lookup and use
android.hardware.keymaster@2.0-service.

IT DOES NOT remove the privileges from keystore and vold to access
the keymaster TA directly.

Test: Run keystore CTS tests
Bug: 32020919

(cherry picked from commit 5090d6f3)

Change-Id: Ib02682da26e2dbcabd81bc23169f9bd0e832eb19

This adds the premissions required for
android.hardware.keymaster@2.0-service to access the keymaster TA
as well as for keystore and vold to lookup and use
android.hardware.keymaster@2.0-service.

IT DOES NOT remove the privileges from keystore and vold to access
the keymaster TA directly.

Test: Run keystore CTS tests
Bug: 32020919
Change-Id: I9467ee29232cc54b48a6dae8ae240656999f73bf