We often see the following denials:

avc: denied { sys_rawio } for comm="update_engine" capability=17 scontext=u:r:update_engine:s0 tcontext=u:r:update_engine:s0 tclass=capability permissive=0
avc: denied { sys_rawio } for comm="boot@1.0-servic" capability=17 scontext=u:r:hal_bootctl_default:s0 tcontext=u:r:hal_bootctl_default:s0 tclass=capability permissive=0

These are benign, so we are hiding them.

Bug: 37778617
Test: Boot device.
Change-Id: Iac196653933d79aa9cdeef7670076f0efc97b44a
(cherry picked from commit bf4afae1)

In kernel 4.7, the capability and capability2 classes were split apart
from cap_userns and cap2_userns (see kernel commit
8e4ff6f228e4722cac74db716e308d1da33d744f). Since then, Android cannot be
run in a container with SELinux in enforcing mode.

This change applies the existing capability rules to user namespaces as
well as the root namespace so that Android running in a container
behaves the same on pre- and post-4.7 kernels.

This is essentially:
  1. New global_capability_class_set and global_capability2_class_set
     that match capability+cap_userns and capability2+cap2_userns,
     respectively.
  2. s/self:capability/self:global_capability_class_set/g
  3. s/self:capability2/self:global_capability2_class_set/g
  4. Add cap_userns and cap2_userns to the existing capability_class_set
     so that it covers all capabilities.  This set was used by several
     neverallow and dontaudit rules, and I confirmed that the new
     classes are still appropriate.

Test: diff new policy against old and confirm that all new rules add
      only cap_userns or cap2_userns;
      Boot ARC++ on a device with the 4.12 kernel.
Bug: crbug.com/754831

Change-Id: I4007eb3a2ecd01b062c4c78d9afee71c530df95f

There's a selinux denial for update_engine after go/aog/530462; the
denial is likely due to the setgid bit of the
update_engine_log_data_file.
Message:
11-11 02:07:54.843   870   870 I auditd  : type=1400 audit(0.0:4): avc:
denied { fsetid } for comm="update_engine" capability=4
scontext=u:r:update_engine:s0 tcontext=u:r:update_engine:s0
tclass=capability permissive=0
11-11 02:07:54.843   870   870 I auditd  : type=1400 audit(0.0:5): avc:
denied { fsetid } for comm="update_engine" capability=4
scontext=u:r:update_engine:s0 tcontext=u:r:update_engine:s0
tclass=capability permissive=0
11-11 02:07:54.843   870   870 I auditd  : type=1400 audit(0.0:4): avc:
denied { fsetid } for comm="update_engine" capability=4
scontext=u:r:update_engine:s0 tcontext=u:r:update_engine:s0
tclass=capability permissive=0
11-11 02:07:54.843   870   870 I auditd  : type=1400 audit(0.0:5): avc:
denied { fsetid } for comm="update_engine" capability=4
scontext=u:r:update_engine:s0 tcontext=u:r:update_engine:s0
tclass=capability permissive=0

Bug: 69197466
Test: denial message gone on sailfish.
Change-Id: I0fdc285e4a4faa8dc37b4907484b3c79d4cc49cf

Add label update_engine_log_data_file for log files created by
update engine in directory /data/misc/update_engine_log.

Bug: 65568605
Test: manual
Change-Id: I379db82a0ea540e41cb3b8e03f93d9ce64fac7c9

New types:
1. proc_random
2. sysfs_dt_firmware_android

Labeled:
1. /proc/sys/kernel/random as proc_random.
2. /sys/firmware/devicetree/base/firmware/android/{compatible, fstab,
vbmeta} as sysfs_dt_firmware_android.

Changed access:
1. uncrypt, update_engine, postinstall_dexopt have access to generic proc
and sysfs labels removed.
2. appropriate permissions were added to uncrypt, update_engine,
update_engine_common, postinstall_dexopt.

Bug: 67416435
Bug: 67416336
Test: fake ota go/manual-ab-ota runs without denials
Test: adb sideload runs without denials to new types
Change-Id: Id31310ceb151a18652fcbb58037a0b90c1f6505a

Grant update_engine access to sysfs.
Ran fake ota go/manual-ab-ota, and this denial was fixed:
avc: denied { read } for pid=912 comm="update_engine" name="compatible"
dev="sysfs" ino=17399 scontext=u:r:update_engine:s0
tcontext=u:object_r:sysfs:s0 tclass=file permissive=0

Test: boots with no new denials
Change-Id: I8697da3af254aea1cec44d9dbb1eca18be31859c

This attribute is being actively removed from policy. Since
attributes are not being versioned, partners must not be able to
access and use this attribute. Move it from private and verify in
the logs that rild and tee are not using these permissions.

Bug: 38316109
Test: build and boot Marlin
Test: Verify that rild and tee are not being granted any of these
      permissions.
Merged-In: I31beeb5bdf3885195310b086c1af3432dc6a349b
Change-Id: I31beeb5bdf3885195310b086c1af3432dc6a349b
(cherry picked from commit 76aab82c)

This attribute is being actively removed from policy. Since
attributes are not being versioned, partners must not be able to
access and use this attribute. Move it from private and verify in
the logs that rild and tee are not using these permissions.

Bug: 38316109
Test: build and boot Marlin
Test: Verify that rild and tee are not being granted any of these
      permissions.
Change-Id: I31beeb5bdf3885195310b086c1af3432dc6a349b

Vendor and system components are only allowed to share files by
passing open FDs over HIDL. Ban all directory access and all file
accesses other than what can be applied to an open file:
stat/read/write/append.

This commit marks core data types as core_data_file_type and bans
access to non-core domains with an exemption for apps. A temporary
exemption is also granted to domains that currently rely on
access with TODOs and bug number for each exemption.

Bug: 34980020
Test: Build and boot Marlin. Make phone call, watch youtube video.
      No new denials observed.
Change-Id: I320dd30f9f0a5bf2f9bb218776b4bccdb529b197

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

Bug: 35721166
Test: Run update_engine_unittest as system user in enforcing mode.
Change-Id: I9cd63b19e6eed3e1291d36d4c342ecf725407232

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>

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

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 6c3f2831)

Allow priv_app, uncrypt, update_engine to access the OTA packages at
/data/ota_package (both A/B and non-A/B). GMSCore (priv_app) checks
the existence of the folder, and downloads the package there if present.

Bug: 28944800
Change-Id: I3c0717861fce7f93b33874a99f6a4a55567612a5

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

update_engine launches the postinstall process and can suspend and
resume it by sending SIGSTOP and SIGCONT. This fixes the following
denials:

update_engine: type=1400 audit(0.0:88): avc: denied { sigstop } for scontext=u:r:update_engine:s0 tcontext=u:r:postinstall:s0 tclass=process permissive=1
update_engine: type=1400 audit(0.0:89): avc: denied { signal } for scontext=u:r:update_engine:s0 tcontext=u:r:postinstall:s0 tclass=process permissive=1

Bug: 28959137
TEST=`update_engine_client --suspend ; update_engine_client --resume` while the device is running postinstall.

(cherry picked from commit 108b74a1)

Change-Id: Iec8e10fe0cfda5c0764d2e5ad90ea1c6dd13dab2

update_engine launches the postinstall process and can suspend and
resume it by sending SIGSTOP and SIGCONT. This fixes the following
denials:

update_engine: type=1400 audit(0.0:88): avc: denied { sigstop } for scontext=u:r:update_engine:s0 tcontext=u:r:postinstall:s0 tclass=process permissive=1
update_engine: type=1400 audit(0.0:89): avc: denied { signal } for scontext=u:r:update_engine:s0 tcontext=u:r:postinstall:s0 tclass=process permissive=1

Bug: 28959137
TEST=`update_engine_client --suspend ; update_engine_client --resume` while the device is running postinstall.

Change-Id: I9890ad0ff7fe04bae1a54fa07c61aafca8de8e66

update_engine can trigger a factory-reset when the update to an older
version or an incompatible version requires it.

Bug: 28700985
TEST=Updated a device with a factory-reset required and the BCB was
written.

(cherry picked from commit 15105ce7)

Change-Id: I7d2efc0e7f164d618cbb3fe190882e4fa8a89bac

update_engine can trigger a factory-reset when the update to an older
version or an incompatible version requires it.

Bug: 28700985
TEST=Updated a device with a factory-reset required and the BCB was
written.

Change-Id: Ief3dd386a14b669141d75b561122a3095efc0a6f

Allow priv_app, uncrypt, update_engine to access the OTA packages at
/data/ota_package (both A/B and non-A/B). GMSCore (priv_app) checks
the existence of the folder, and downloads the package there if present.

Bug: 28944800
Change-Id: I3c0717861fce7f93b33874a99f6a4a55567612a5

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

We decided a different approach for these policies in the
meeting today.

This reverts commit 5507fa66.

Bug: 28008031
Change-Id: Id86520660bdbc3fc36ac4acf51082547d6a559eb

update_engine had an automatic transition to the "postinstall" domain
when executing a "postinstall_file" which required it to be an
entrypoint. This patch removes this automatic transition and the
associated rules in update_engine.te, removing as well the need to
add exec_type to postinstall_file. Instead, update_engine now makes
this transition explicit by calling setexeccon(3).

Bug: 28008031
TEST=make dist; Deployed an update to edison-eng: postinstall runs as "postinstall" domain.

Change-Id: I2b799ac4808c90b010a9e776aaa7015020a94b49

When using the A/B updater, a device specific hook is sometimes needed
to run after the new partitions are updated but before rebooting into
the new image. This hook is referred to throughout the code as the
"postinstall" step.

This patch creates a new execution domain "postinstall" which
update_engine will use to run said hook. Since the hook needs to run
from the new image (namelly, slot "B"), update_engine needs to
temporarly mount this B partition into /postinstall and then run a
program from there.

Since the new program in B runs from the old execution context in A, we
can't rely on the labels set in the xattr in the new filesystem to
enforce the policies baked into the old running image. Instead, when
temporarily mounting the new filesystem in update_engine, we override
all the new file attributes with the new postinstall_file type by
passing "context=u:object_r:postinstall_file:s0" to the mount syscall.
This allows us to set new rules specific to the postinstall environment
that are consistent with the rules in the old system.

Bug: 27177071
TEST=Deployed a payload with a trivial postinstall script to edison-eng.

(cherry picked from commit 6cb2c893)

Change-Id: I49a529eecf1ef0524819470876ef7c8c2659c7ef

When using the A/B updater, a device specific hook is sometimes needed
to run after the new partitions are updated but before rebooting into
the new image. This hook is referred to throughout the code as the
"postinstall" step.

This patch creates a new execution domain "postinstall" which
update_engine will use to run said hook. Since the hook needs to run
from the new image (namelly, slot "B"), update_engine needs to
temporarly mount this B partition into /postinstall and then run a
program from there.

Since the new program in B runs from the old execution context in A, we
can't rely on the labels set in the xattr in the new filesystem to
enforce the policies baked into the old running image. Instead, when
temporarily mounting the new filesystem in update_engine, we override
all the new file attributes with the new postinstall_file type by
passing "context=u:object_r:postinstall_file:s0" to the mount syscall.
This allows us to set new rules specific to the postinstall environment
that are consistent with the rules in the old system.

Bug: 27177071
TEST=Deployed a payload with a trivial postinstall script to edison-eng.

Change-Id: Ib06fab92afb45edaec3c9c9872304dc9386151b4

update_engine needs to access bootctrl_block_device to get and set the slot to boot.
avc: denied { write } for name="mmcblk0boot1" dev="tmpfs" ino=1266 scontext=u:r:update_engine:s0 tcontext=u:object_r:bootctrl_block_device:s0 tclass=blk_file
avc: denied { open } for path="/dev/block/mmcblk0boot1" dev="tmpfs" ino=1266 scontext=u:r:update_engine:s0 tcontext=u:object_r:bootctrl_block_device:s0 tclass=blk_file

Also track the name change of the native binder service.
avc:  denied  { add } for service=android.os.UpdateEngineService pid=210 uid=0 scontext=u:r:update_engine:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager

Bug: 27106053
Change-Id: Idbfef18578489db33fead0721e8f26d63db5ce09
(cherry picked from commit 3ec34ceb)

update_engine needs to access bootctrl_block_device to get and set the slot to boot.
avc: denied { write } for name="mmcblk0boot1" dev="tmpfs" ino=1266 scontext=u:r:update_engine:s0 tcontext=u:object_r:bootctrl_block_device:s0 tclass=blk_file
avc: denied { open } for path="/dev/block/mmcblk0boot1" dev="tmpfs" ino=1266 scontext=u:r:update_engine:s0 tcontext=u:object_r:bootctrl_block_device:s0 tclass=blk_file

Also track the name change of the native binder service.
avc:  denied  { add } for service=android.os.UpdateEngineService pid=210 uid=0 scontext=u:r:update_engine:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager

Bug: 27106053
Change-Id: Idbfef18578489db33fead0721e8f26d63db5ce09

Register service with servicemanager and name the context.

avc: denied { call } for scontext=u:r:update_engine:s0 tcontext=u:r:servicemanager:s0 tclass=binder
avc: denied { add } for service=android.os.IUpdateEngine scontext=u:r:update_engine:s0 tcontext=u:object_r:update_engine_service:s0 tclass=service_manager

Also allow priv_app to communicate with update_engine.

avc: denied { find } for service=android.os.IUpdateEngine scontext=u:r:priv_app:s0:c512,c768 tcontext=u:object_r:update_engine_service:s0 tclass=service_manager
avc: denied { call } for scontext=u:r:priv_app:s0:c512,c768 tcontext=u:r:update_engine:s0 tclass=binder
avc: denied { call } for scontext=u:r:update_engine:s0 tcontext=u:r:priv_app:s0 tclass=binder

Change-Id: Ib4498717c1a72f5faab5ea04c636924ee4eb412c

This allow bspatch to have same perssion as update_engine.

Also added a rule to allow update_engine to execute bspatch.

Bug: 24478450
Test: No more permission deny during delta update.

Change-Id: If94bc703b2f3fc32f901f0d7f300934316d4e9a4

The update_engine daemon from Brillo is expected to be used also in
Android so move its selinux policy to AOSP.

Put update_engine in the whitelist (currently only has the recovery
there) allowing it to bypass the notallow for writing to partititions
labeled as system_block_device.

Also introduce the misc_block_device dev_type as update_engine in some
configurations may need to read/write the misc partition. Start
migrating uncrypt to use this instead of overly broad
block_device:blk_file access.

Bug: 23186405
Test: Manually tested with Brillo build.

Change-Id: Icf8cdb4133d4bbdf14bacc6c0fa7418810ac307a
(cherry picked from commit a10f789d)

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

The update_engine daemon from Brillo is expected to be used also in
Android so move its selinux policy to AOSP.

Put update_engine in the whitelist (currently only has the recovery
there) allowing it to bypass the notallow for writing to partititions
labeled as system_block_device.

Also introduce the misc_block_device dev_type as update_engine in some
configurations may need to read/write the misc partition. Start
migrating uncrypt to use this instead of overly broad
block_device:blk_file access.

Bug: 23186405
Test: Manually tested with Brillo build.

Change-Id: Icf8cdb4133d4bbdf14bacc6c0fa7418810ac307a