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

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

Domains which are clients of Sensors HAL, such as system_server, are
granted rules targeting hal_sensors only when the Sensors 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_sensors are
not granted to client domains.

Domains which offer a binderized implementation of Sensors HAL, such
as hal_sensors_default domain, are always granted rules targeting
hal_sensors.

P. S. This commit also removes
  allow system_server sensors_device:chr_file rw_file_perms
because this is device-specific and thus not needed in device-agnostic
policy. The device-specific policy of the affected devices already has
this rule.

Test: Device boots, no new denials
Test: adb shell dumpsys sensorservice
      lists tons of sensors
Test: Proprietary sensors test app indicates that there are sensors
      and that the app can register to listen for updates for sensors
      and that such updates arrive to the app.
Bug: 34170079
Change-Id: I61bf779070eabcb64ae73724d62b6e837319a668

Note: The existing rules allowing socket communication will be removed
once we  migrate over to HIDL completely.

(cherry-pick of 2a9595ed) 
Bug: 34603782
Test: Able to connect to wifi networks.
Test: Will be sending for full wifi integration tests
(go/wifi-test-request)
Change-Id: I9ee238fd0017ec330f6eb67ef9049211f7bd4615

This starts with the reduction in the number of services that
ephemeral apps can access. Prior to this commit, ephemeral apps were
permitted to access most of the service_manager services accessible
by conventional apps. This commit reduces this set by removing access
from ephemeral apps to:
* gatekeeper_service,
* sec_key_att_app_id_provider_service,
* wallpaper_service,
* wifiaware_service,
* wifip2p_service,
* wifi_service.

Test: Device boots up fine, Chrome, Play Movies, YouTube, Netflix, work fine.
Bug: 33349998
Change-Id: Ie4ff0a77eaca8c8c91efda198686c93c3a2bc4b3

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

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

Domains which are clients of Wi-Fi HAL, such as system_server domain,
are granted rules targeting hal_wifi only when the Wi-Fi 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_wifi are
not granted to client domains.

Domains which offer a binderized implementation of Wi-Fi HAL, such as
hal_wifi_default domain, are always granted rules targeting hal_wifi.

Test: Setup Wizard (incl. adding a Google Account) completes fine with
      Wi-Fi connectivity only
Test: Toggle Wi-Fi off, on, off, on
Test: Use System UI to see list of WLANs and connect to one which does
      not require a password, and to one which requries a PSK
Test: ip6.me loads fine in Chrome over Wi-Fi
Bug: 34170079

Change-Id: I7a216a06727c88b7f2c23d529f67307e83bed17f

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

Domains which are clients of Dumpstate HAL, such as dumpstate domain,
are granted rules targeting hal_dumpstate only when the Dumpstate 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_dumpstate are not granted to client domains.

Domains which offer a binderized implementation of Dumpstate HAL, such
as hal_dumpstate_default domain, are always granted rules targeting
hal_dumpstate.

Test: adb bugreport
Test: Take bugreport through system UI
Bug: 34170079
Change-Id: I3e827534af03cdfa876921c5fa4af3a53025ba27

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

Domains which are clients of Fingerprint HAL, such as system_server
domain, are granted rules targeting hal_fingerprint only when the
Fingerprint 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_fingerprint are not granted to client domains.

Domains which offer a binderized implementation of Fingerprint HAL,
such as hal_fingerprint_default domain, are always granted rules
targeting hal_fingerprint.

NOTE: This commit also removes unnecessary allow rules from
Fingerprint HAL, such access to servicemanager (not hwservicemanager)
and access to keystore daemon over Binder IPC. Fingerprint HAL does
not use this functionality anyway and shouldn't use it either.

Test: Enable fingerprint + PIN secure lock screen, confirm it unlocks
      with fingerprint or PIN
Test: Disable PIN (and thus fingerprint) secure lock screen
Test: make FingerprintDialog, install, make a fake purchase
Test: Add fingerprint_hidl_hal_test to device.mk, build & add to device,
      adb shell stop,
      adb shell /data/nativetest64/fingerprint_hidl_hal_test/fingerprint_hidl_hal_test -- all tests pass
Bug: 34170079

Change-Id: I6951c0f0640194c743ff7049357c77f5f21b71a1

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

Domains which are clients of DRM HAL, such as mediadrmserver domain,
are granted rules targeting hal_drm only when the DRM 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_drm
are not granted to client domains.

Domains which offer a binderized implementation of DRM HAL, such as
hal_drm_default domain, are always granted rules targeting hal_drm.

Test: Play movie using Google Play Movies
Test: Play movie using Netflix
Bug: 34170079
Change-Id: I3ab0e84818ccd61e54b90f7ade3509b7dbf86fb9

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

Domains which are clients of Bluetooth HAL, such as bluetooth domain,
are granted rules targeting hal_bluetooth only when the Bluetooth 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_bluetooth are not granted to client domains.

Domains which offer a binderized implementation of Bluetooth HAL, such
as hal_bluetooth_default domain, are always granted rules targeting
hal_bluetooth.

Test: Toggle Bluetooth off and on
Test: Pair with another Android, and transfer a file to that Android
      over Bluetooth
Test: Pair with a Bluetooth speaker, play music through that
      speaker over Bluetooth
Test: Add bluetooth_hidl_hal_test to device.mk, build & add to device,
      adb shell stop,
      adb shell /data/nativetest64/bluetooth_hidl_hal_test/bluetooth_hidl_hal_test
Bug: 34170079
Change-Id: I05c3ccf1e98cbbc1450a81bb1000c4fb75eb8a83

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

Domains which are clients of Camera HAL, such as cameraserver domain,
are granted rules targeting hal_camera only when the Camera 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_camera are
not granted to client domains.

Domains which offer a binderized implementation of Camera HAL, such
as hal_camera_default domain, are always granted rules targeting
hal_camera.

Test: Take non-HDR photo using Google Camera app
Test: Take HDR photo using Google Camera app
Test: Record video using Google Camera app
Bug: 34170079
Change-Id: I463646cf79fede57f11ccd4ec2cbc37a4fff141e

This starts the switch for HAL policy to the approach where:
* domains which are clients of Foo HAL are associated with
  hal_foo_client attribute,
* domains which offer the Foo HAL service over HwBinder are
  associated with hal_foo_server attribute,
* policy needed by the implementation of Foo HAL service is written
  against the hal_foo attribute. This policy is granted to domains
  which offer the Foo HAL service over HwBinder and, if Foo HAL runs
  in the so-called passthrough mode (inside the process of each
  client), also granted to all domains which are clients of Foo HAL.
  hal_foo is there to avoid duplicating the rules for hal_foo_client
  and hal_foo_server to cover the passthrough/in-process Foo HAL and
  binderized/out-of-process Foo HAL cases.

A benefit of associating all domains which are clients of Foo HAL with
hal_foo (when Foo HAL is in passthrough mode) is that this removes the
need for device-specific policy to be able to reference these domains
directly (in order to add device-specific allow rules). Instead,
device-specific policy only needs to reference hal_foo and should no
longer need to care which particular domains on the device are clients
of Foo HAL. This can be seen in simplification of the rules for
audioserver domain which is a client of Audio HAL whose policy is
being restructured in this commit.

This commit uses Audio HAL as an example to illustrate the approach.
Once this commit lands, other HALs will also be switched to this
approach.

Test: Google Play Music plays back radios
Test: Google Camera records video with sound and that video is then
      successfully played back with sound
Test: YouTube app plays back clips with sound
Test: YouTube in Chrome plays back clips with sound
Bug: 34170079
Change-Id: I2597a046753edef06123f0476c2ee6889fc17f20

Motivation:
Provide the ability to phase in new security policies by
applying them to apps with a minimum targetSdkVersion.

Place untrusted apps with targetSdkVersion<=25 into the
untrustd_app_25 domain. Apps with targetSdkVersion>=26 are placed
into the untrusted_app domain. Common rules are included in the
untrusted_app_all attribute. Apps with a more recent targetSdkVersion
are granted fewer permissions.

Test: Marlin builds and boots. Apps targeting targetSdkVersion<=25
run in untrusted_app_25 domain. Apps targeting the current development
build >=26 run in the untrusted_app domain with fewer permissions. No
new denials observed during testing.
Bug: 34115651
Bug: 35323421
Change-Id: Ie6a015566fac07c44ea06c963c40793fcdc9a083

This change adds selinux policy for configstore@1.0 hal. Currently, only
surfaceflinger has access to the HAL, but need to be widen.

Bug: 34314793
Test: build & run

Merged-In: I40e65032e9898ab5f412bfdb7745b43136d8e964
Change-Id: I40e65032e9898ab5f412bfdb7745b43136d8e964
(cherry picked from commit 5ff0f178)

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

Bug: 31015010

cherry-pick from b6e4d4bd

Test: checked for selinux denial msgs in the dmesg logs.
Change-Id: I8285ea05162ea0d75459e873e5c2bad2dbc7e5ba

bug:32815560
Change-Id: I494141b47fcd2e7e0cc02aa58d8df9a222060b3f

Test: No change to SELinux policy
Change-Id: I45d6d6ab0538b9d4768b922cfdc2c972272d0b18

- Allow cameraservice to talk to hwbinder, hwservicemanager
- Allow hal_camera to talk to the same interfaces as cameraservice

Test: Compiles, confirmed that cameraservice can call hwservicemanager
Bug: 32991422
Change-Id: Ied0a3f5f7149e29c468a13887510c78d555dcb2a

This marks all HAL domain implementations with the haldomain attribute
so that rules can be written which apply to all HAL implementations.

This follows the pattern used for appdomain, netdomain and
bluetoothdomain.

Test: No change to policy according to sesearch.
Bug: 34180936
Change-Id: I0cfe599b0d49feed36538503c226dfce41eb65f6

Move from fingerprintd to new fingerprint_hal and update SeLinux policy.

Test: Boot with no errors related to fingerprint sepolicy
Bug: 33199080
Change-Id: Idfde0cb0530e75e705033042f64f3040f6df22d6

The following are the avc denials that are addressed:

avc: denied { call } for pid=889 comm="system_server"
scontext=u:r:system_server:s0 tcontext=u:r:hal_gnss_default:s0
tclass=binder permissive=0

avc: denied { call } for scontext=u:r:hal_gnss_default:s0
tcontext=u:r:system_server:s0 tclass=binder permissive=0

avc: denied { read } for name="hw" dev="mmcblk0p43" ino=1837
scontext=u:r:hal_gnss_default:s0 tcontext=u:object_r:system_file:s0
tclass=dir permissive=0

avc: denied { open } for path="/system/lib64/hw" dev="mmcblk0p43"
ino=1837 scontext=u:r:hal_gnss_default:s0
tcontext=u:object_r:system_file:s0 tclass=dir permissive=0

Bug:31974439

Test: Checked that there no more related avc denial messages related to
the GNSS HAL in dmesg.

Change-Id: I5b43dc088017a5568dd8e442726d2bf52e95b1d5

Bug: 31972505
Test: VTS test passes, Bluetooth starts/stops
Change-Id: Ic068c9fca7c50e63c5b6e3d86a2ee6cc53207e08

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

Adding sepoilcy for sensors.

Test: Sensors work.
Change-Id: Ibbf0c1a22654a17b1573e3761ea9ccd816150255

Adding sepolicty for contexthub service.

Test: GTS tests pass.
Change-Id: I2576b8028d12a31151d7b7869679b853eb16c75e

Test: Verified that WIP telephony and BT SAP CLs work fine with this change
https://android-review.googlesource.com/#/q/topic:%22Basic+radio+service+and+client%22+(status:open+OR+status:merged)
https://android-review.googlesource.com/#/q/topic:%22SAP+HAL%22+(status:open+OR+status:merged)
Bug: 32020264
Change-Id: If15820d43e324d80e35808a292ee811f98d499cc

Bug: http://b/32905206



Test: Boot sailfish and no new selinux failures observed in logs

Change-Id: Id9a46180074a61f8cf8d176a7b2ebc995a13b9f9
Signed-off-by: Sandeep Patil <sspatil@google.com>

- Also allow dumpstate to talk to hal_dumpstate.

Bug: 31982882
Test: compiles
Change-Id: Ib9cf0027ee7e71fa40b9ccc29fc8dccea6977e5c

Bug: 32123421
Bug: 32905206

Test: compiles, nfc works
Change-Id: Ibf72ef70255573e4df0863ea640354b3c37eb47d

Test: logging confirms service runs on boot
Change-Id: If86fa7daf4a626b3e04fa0d2677d4cb590eb71ce
Signed-off-by: Connor O'Brien <connoro@google.com>

HAL policy defines how the platform and a given HAL interact, but not how the
HAL is implemented.  This policy should be represented as an attribute that all
processes implementing the HAL can include.

Bug: 32123421
Test: Builds.
Change-Id: I17e5612c0835773c28e14f09e2ce7bdc3f210c15

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

The recovery flow for A/B devices allows to sideload an OTA downloaded
to a desktop and apply from recovery. This patch allows the "recovery"
context to perform all the operations required to apply an update as
update_engine would do in the background. These rules are now extracted
into a new attributte called update_engine_common shared between
recovery and update_engine.

Bug: 27178350

(cherry picked from commit d63084d3)

Change-Id: I1f3e1e83a21e37e09b69cd9c497f87b42b9cbeb1

The recovery flow for A/B devices allows to sideload an OTA downloaded
to a desktop and apply from recovery. This patch allows the "recovery"
context to perform all the operations required to apply an update as
update_engine would do in the background. These rules are now extracted
into a new attributte called update_engine_common shared between
recovery and update_engine.

Bug: 27178350
Change-Id: I97b301cb2c039fb002e8ebfb23c3599463ced03a

The boot_control HAL is library loaded by our daemons (like
update_engine and update_verifier) that interacts with the bootloader.
The actual implementation of this library is provided by the vendor and
its runtime permissions are tied to this implementation which varies a
lot based on how the bootloader and the partitions it uses are
structured.

This patch moves these permissions to an attribute so the attribute can
be expanded on each device without the need to repeat that on each one
of our daemons using the boot_control HAL.

Bug: 27107517

(cherry picked from commit 0f8d9261)

Change-Id: Icb2653cb89812c0de81381ef48280e4ad1e9535c

The boot_control HAL is library loaded by our daemons (like
update_engine and update_verifier) that interacts with the bootloader.
The actual implementation of this library is provided by the vendor and
its runtime permissions are tied to this implementation which varies a
lot based on how the bootloader and the partitions it uses are
structured.

This patch moves these permissions to an attribute so the attribute can
be expanded on each device without the need to repeat that on each one
of our daemons using the boot_control HAL.

Bug: 27107517
Change-Id: Idfe6a208720b49802b03f70fee4a3e73030dae2e

Restrict the ability of the shell to set the log.*
properties. Namely: only allow the shell to set
such properities on eng and userdebug builds.

The shell (and other domains) can continue to
read log.* properties on all builds.

While there: harmonize permissions for log.* and
persist.log.tag. Doing so introduces two changes:
- log.* is now writable from from |system_app|. This
  mirrors the behavior of persist.log.tag, which is
  writable to support "Developer options" ->
  "Logger buffer sizes" -> "Off".
  (Since this option is visible on user builds, the
  permission is enabled for all builds.)
- persist.log.tag can now be set from |shell| on
  userdebug_or_eng().

BUG=28221972
TEST=manual (see below)

Testing details
- user build (log.tag)
  $ adb shell setprop log.tag.foo V
  $ adb shell getprop log.tag
  <blank line>
  $ adb bugreport | grep log.tag.foo
  [  146.525836] init: avc:  denied  { set } for property=log.tag.foo pid=4644 uid=2000 gid=2000 scontext=u:r:shell:s0 tcontext=u:object_r:log_prop:s0 tclass=property_service permissive=0
  [  146.525878] init: sys_prop: permission denied uid:2000  name:log.tag.foo
- userdebug build (log.tag)
  $ adb shell getprop log.tag.foo
  <blank line>
  $ adb shell setprop log.tag.foo V
  $ adb shell getprop log.tag.foo
  V
- user build (persist.log.tag)
  $ adb shell getprop | grep log.tag
  <no match>
  - Developer options -> Logger buffer sizes -> Off
  $ adb shell getprop | grep log.tag
  [persist.log.tag]: [Settings]
  [persist.log.tag.snet_event_log]: [I]

Change-Id: Idf00e7a623723a7c46bf6d01e386aeca92b2ad75

Enable checkfc to check *_contexts against a set of valid attributes
which must be associated with all types in the contexts file that
is being checked.

Since it's imperative that checkfc knows which file its checking to
choose the proper attribute set, the -s option is introduced to
indicate the service_contexts file. The property_contexts file continues
to use the existing -p and file_contexts requires no specification, aka
it's the default.

Failure examples:
file_contexts:
Error: type "init" is not of set: "fs_type, dev_type, file_type"

service_contexts:
Error: type "init_exec" is not of set: "service_manager_type"

property_contexts:
Error: type "bluetooth_service" is not of set: "property_type"

Change-Id: I62077e4d0760858a9459e753e14dfd209868080f
Signed-off-by: William Roberts <william.c.roberts@intel.com>

Instead of allowing global read access to all properties,
only allow read access to the properties which are part of
core SELinux policy. Device-specific policies are no longer
readable by default and need to be granted in device-specific
policy.

Grant read-access to any property where the person has write
access. In most cases, anyone who wants to write a property
needs read access to that property.

Change-Id: I2bd24583067b79f31b3bb0940b4c07fc33d09918