Denial message:
avc: denied { write } for pid=640 comm="update_verifier" name="kmsg"
dev="tmpfs" ino=13951 scontext=u:r:update_verifier:s0
tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0

Bug: 64713327
Test: update_verifier logs successfully during boot time.
Change-Id: I421b1e6660239e5ffc624e504f5945d400510407

Currently update_verifier only verifies the blocks when dm-verity is in
'enforcing' mode; and dm-verity will reboot the device upon detection of
errors. However, sometimes the verity mode is not guaranteed to be
correct. When mode is 'eio' for example, dm-verity will not trigger
a reboot but rather fail the read. So update_verifier need to take the
responsibility to reboot the device. Otherwise the device will continue
to boot without setting the flag "isSlotMarkedSuccessful".

Denial message:
update_verifier: type=1400 audit(0.0:18): avc: denied { write } for
name="property_service" dev="tmpfs" ino=14678 scontext=u:r:update_verifier:s0
tcontext=u:object_r:property_socket:s0 tclass=sock_file permissive=0

Bug: 36260064
Test: powerctl property sets successfully

Change-Id: I1260e60f2ef4db50573e515ba95c332512c8ae62
(cherry picked from commit 0d8c1e0a)

Currently update_verifier only verifies the blocks when dm-verity is in
'enforcing' mode; and dm-verity will reboot the device upon detection of
errors. However, sometimes the verity mode is not guaranteed to be
correct. When mode is 'eio' for example, dm-verity will not trigger
a reboot but rather fail the read. So update_verifier need to take the
responsibility to reboot the device. Otherwise the device will continue
to boot without setting the flag "isSlotMarkedSuccessful".

Denial message:
update_verifier: type=1400 audit(0.0:18): avc: denied { write } for
name="property_service" dev="tmpfs" ino=14678 scontext=u:r:update_verifier:s0
tcontext=u:object_r:property_socket:s0 tclass=sock_file permissive=0

Bug: 36260064
Test: powerctl property sets successfully
Change-Id: I7431f87e2d61be1425397732aebb369d4ad4c26c

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

Domains which are clients of Boot Control HAL, such as update_server,
are granted rules targeting hal_bootctl only when the Boot Control 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_bootctl are not granted to client domains.

Domains which offer a binderized implementation of Boot Control HAL,
such as hal_bootctl_default domain, are always granted rules targeting
hal_bootctl.

P. S. This commit removes direct access to Boot Control HAL from
system_server because system_server is not a client of this HAL. This
commit also removes bootctrl_block_device type which is no longer
used. Finally, boot_control_hal attribute is removed because it is now
covered by the hal_bootctl attribute.

Test: Device boots up, no new denials
Test: Reboot into recovery, sideload OTA update succeeds
Test: Apply OTA update via update_engine:
      1. make dist
      2. Ensure device has network connectivity
      3. ota_call.py -s <serial here> out/dist/sailfish-ota-*.zip
Bug: 34170079
Change-Id: I9c410c092069e431a3852b66c04c4d2a9f1a25cf

Update_verifier will read dm-wrapped system/vendor partition. Therefore,
change the sepolicy accordingly.

Here's the denied message:
update_verifier: type=1400 audit(0.0:131): avc: denied { read } for
name="dm-0" dev="tmpfs" ino=15493 scontext=u:r:update_verifier:s0
tcontext=u:object_r:dm_device:s0 tclass=blk_file permissive=0

Bug: 34391662
Test: Read of /dev/block/dm-0 succeeds during boot time.
Change-Id: I23325bd92f6e28e9b1d62a0f2348837cece983d1

Allow update_verifier to load the boot_control_hal in passthrough mode.

Test: update_verifier works, no denials
Bug: 34656553
Change-Id: I5c20ce67c8f1fd195f2429dae497221514ed95a8

The service running the boot control HAL needs the permissions
provided by the boot_control_hal attribute. update_engine and
update_verifier still also need these permissions in order
to successfully call the new HAL in pass-through mode, but also
need permission to call the new service.

Bug: 31864052
Test: Built and confirmed no permission denials.
Change-Id: I2a6fdd5cf79b9e461d7cc14bd5b7abd6481ed911
Signed-off-by: Connor O'Brien <connoro@google.com>

This reverts commit 1f329465.

Bug: 32973182
Change-Id: Ic0277b38b0249710a4f1fc362e777f3880ff096b

Grant boot_control_hal permissions to the hal_boot service;
update_engine and update_verifier can call that service rather
than using those permissions themselves.

Bug: 31864052
Test: `bootctl set-active-boot-slot 1`
Change-Id: I5188bc32e7933d4a0f5135b3246df119d3523d69

Test: Flashed device and verified no update_verifier permission denials
Change-Id: I5de063c202aefef399645b153f68ff7909989eba
Signed-off-by: Connor O'Brien <connoro@google.com>

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

(cherry picked from commit 5d8d2dc9)

Grant update_verifier the permissions to read /data/ota_package/
and the blocks on system partition.

The denial messages:
update_verifier: type=1400 audit(0.0:29): avc: denied { read }
scontext=u:r:update_verifier:s0 tcontext=u:object_r:ota_package_file:s0 tclass=file permissive=1

update_verifier: type=1400 audit(0.0:30): avc: denied { open }
scontext=u:r:update_verifier:s0 tcontext=u:object_r:ota_package_file:s0 tclass=file permissive=1

update_verifier: type=1400 audit(0.0:31): avc: denied { read } dev="tmpfs"
scontext=u:r:update_verifier:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=1

update_verifier: type=1400 audit(0.0:32): avc: denied { open } dev="tmpfs"
scontext=u:r:update_verifier:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=1

Test: On device, update_verifier reads the blocks successfully during boot time.
Bug: 30020920

Change-Id: I10777c1e6ba649b82c4a73171124742edeb05997

update_verifier calls bootcontrol HAL to mark the currently booting slot
as successfully booted.

avc: denied { search } for name="block" dev="tmpfs" scontext=u:r:update_verifier:s0 tcontext=u:object_r:block_device:s0 tclass=dir permissive=0
avc: denied { search } for name="block" dev="tmpfs" scontext=u:r:update_verifier:s0 tcontext=u:object_r:block_device:s0 tclass=dir permissive=0

Bug: 29569601
Test: Device boots up with no update_verifier denials and 'bootctl is-slot-marked-successful 0' returns 0.
Change-Id: I1baa7819bc829e3c4b83d7168008a5b06b01cc9f

Grant update_verifier the permissions to read /data/ota_package/
and the blocks on system partition.

The denial messages:
update_verifier: type=1400 audit(0.0:29): avc: denied { read } for name="care_map.txt" dev="sda35"
ino=1368066 scontext=u:r:update_verifier:s0 tcontext=u:object_r:ota_package_file:s0 tclass=file permissive=1

update_verifier: type=1400 audit(0.0:30): avc: denied { open } for path="/data/ota_package/care_map.txt" dev="sda35"
ino=1368066 scontext=u:r:update_verifier:s0 tcontext=u:object_r:ota_package_file:s0 tclass=file permissive=1

update_verifier: type=1400 audit(0.0:31): avc: denied { read } for name="sda33" dev="tmpfs" ino=5613
scontext=u:r:update_verifier:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=1

update_verifier: type=1400 audit(0.0:32): avc: denied { open } for path="/dev/block/sda33" dev="tmpfs" ino=5613
scontext=u:r:update_verifier:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=1

Test: On sailfish, update_verifier reads the blocks successfully during boot time.
Bug: 30020920

Change-Id: I10777c1e6ba649b82c4a73171124742edeb05997

update_verifier calls bootcontrol HAL to mark the currently booting slot
as successfully booted.

avc: denied { search } for name="block" dev="tmpfs" ino=15510 scontext=u:r:update_verifier:s0 tcontext=u:object_r:block_device:s0 tclass=dir permissive=0
avc: denied { search } for name="block" dev="tmpfs" ino=15510 scontext=u:r:update_verifier:s0 tcontext=u:object_r:block_device:s0 tclass=dir permissive=0

Bug: 29569601
Test: Marlin boots up with no update_verifier denials and 'bootctl is-slot-marked-successful 0' returns 0.
Change-Id: I1baa7819bc829e3c4b83d7168008a5b06b01cc9f

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

Bug: 26039641
Change-Id: Ifd96b105f054b67f881529db3fe94718cab4a0f4
(cherry picked from commit 8eaf2585)

Bug: 26039641
Change-Id: Ifd96b105f054b67f881529db3fe94718cab4a0f4