tequilaOS/platform_system_sepolicy
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_system_sepolicy/microdroid/system/private/property_contexts

107 lines
5.3 KiB
Text
Raw Normal View History

Move microdroid sepolicy to system/sepolicy Bug: 190511750 Test: boot microdroid Change-Id: I4aa4a56e9be5103d70469c3508110a973f3e4f12
2021-07-19 09:48:34 +02:00
# property contexts for microdroid
# microdroid only uses much fewer properties than normal Android, so every property is listed here.
# The only exceptions are "debug.", "init.svc_debug_pid.", and "ctl." properties.
debug. u:object_r:debug_prop:s0 prefix
init.svc_debug_pid. u:object_r:init_svc_debug_prop:s0 prefix int
ctl.sigstop_on$ u:object_r:ctl_sigstop_prop:s0
ctl.sigstop_off$ u:object_r:ctl_sigstop_prop:s0
ctl.start$ u:object_r:ctl_start_prop:s0
ctl.stop$ u:object_r:ctl_stop_prop:s0
ctl.restart$ u:object_r:ctl_restart_prop:s0
ctl.interface_start$ u:object_r:ctl_interface_start_prop:s0
ctl.interface_stop$ u:object_r:ctl_interface_stop_prop:s0
ctl.interface_restart$ u:object_r:ctl_interface_restart_prop:s0
ctl.start$adbd u:object_r:ctl_adbd_prop:s0
ctl.stop$adbd u:object_r:ctl_adbd_prop:s0
ctl.restart$adbd u:object_r:ctl_adbd_prop:s0
ctl.stop$apexd u:object_r:ctl_apexd_prop:s0
Microdroid boot process is controlled by microdroid_manager Previously, the boot process of microdroid was mostly implemented in the init.rc file. microdroid_manager was started first in the background, then apexd, apkdmverity, and zipfuse were executed in sequence. However, in order to correctly implement the app payload verification scheme, most of the early boot process has to be controlled by microdroid_manager. Specifically, apkdmverity should be started "after" the apk roothash is read from the instance disk by microdroid_manager. As an alternative, we could let apkdmverity the read instance disk by itself. However, this is undesirable because doing so requires multiple processes - microdroid_manager and apkdmverity - have access to the instance disk and more seriously the secret key to decrypt it. Another alternative is to let microdroid_manager do the dm-verity configuration which apkdmverity does. This also is considered undesirable because then we would give the permissions for configuring dm-verity devices to microdroid_manager which is a long-running daemon process. Note that apkdmverity is not a daemon process. This CL introduces a few number of changes which are required to let microdroid_manager directly control the early boot process: 1) microdroid_manager is allowed to start the services apkdmverity and zipfuse by using the `ctl.start` sysprop. 2) apkdmverity is allowed to use bootstrap bionic libraries as it is now executed before APEXd activates the APEXes. 3) A new sysprop `microdroid_manager.apk_roothash` is added. It is written by microdroid_manager and read by apkdmverity. It contains the roothash read from the instance disk. This value is not a secret. 4) Another new sysprop `apex_config.done` is added. It is set by init just after `perform_apex_config` and read by microdroid_manager. Microdroid_manager uses this to wait until linker configuration is ready so that it can execute app payloads with the config. Bug: 193504400 Test: atest MicrodroidHostTestCases Change-Id: If29ce17d7a6cb4859e8ceeffb321724e7f11bf82
2021-09-06 08:39:31 +02:00
ctl.start$apkdmverity u:object_r:ctl_apkdmverity_prop:s0
ctl.start$zipfuse u:object_r:ctl_zipfuse_prop:s0
Move microdroid sepolicy to system/sepolicy Bug: 190511750 Test: boot microdroid Change-Id: I4aa4a56e9be5103d70469c3508110a973f3e4f12
2021-07-19 09:48:34 +02:00
ctl.fuse_ u:object_r:ctl_fuse_prop:s0
ctl.console u:object_r:ctl_console_prop:s0
ctl. u:object_r:ctl_default_prop:s0
sys.init.perf_lsm_hooks u:object_r:init_perf_lsm_hooks_prop:s0 exact bool
service.adb.root u:object_r:shell_prop:s0 exact bool
ro.logd.kernel u:object_r:logd_prop:s0 exact bool
ro.boottime.adbd u:object_r:boottime_prop:s0 exact int
SELinux policy for authfs_service and authfs authfs_service is a binder service on microdroid. Upon a request by the client, the service will create the mount directory, execute authfs to mount the FUSE, and finally unmount and delete the mount directory. authfs currently requires more privileges than it should, but it's ok because the client owns the VM, and all input will be verified by signatures. But there is plan to keep the privileges isoated in the service (b/195554831). Bug: 194717985 Bug: 195554831 Test: Start the service from init, use a test executable to call the service API. Only observed denial from the test executable. Change-Id: Ie53aa9e2796433fc3182357039d0b7ba1c0848ef
2021-08-04 02:26:38 +02:00
ro.boottime.authfs_service u:object_r:boottime_prop:s0 exact int
Move microdroid sepolicy to system/sepolicy Bug: 190511750 Test: boot microdroid Change-Id: I4aa4a56e9be5103d70469c3508110a973f3e4f12
2021-07-19 09:48:34 +02:00
ro.boottime.hwservicemanager u:object_r:boottime_prop:s0 exact int
ro.boottime.init u:object_r:boottime_prop:s0 exact int
ro.boottime.init.cold_boot_wait u:object_r:boottime_prop:s0 exact int
ro.boottime.init.first_stage u:object_r:boottime_prop:s0 exact int
ro.boottime.init.modules u:object_r:boottime_prop:s0 exact int
ro.boottime.init.selinux u:object_r:boottime_prop:s0 exact int
ro.boottime.keystore2 u:object_r:boottime_prop:s0 exact int
ro.boottime.logd u:object_r:boottime_prop:s0 exact int
ro.boottime.logd-reinit u:object_r:boottime_prop:s0 exact int
ro.boottime.microdroid_manager u:object_r:boottime_prop:s0 exact int
ro.boottime.servicemanager u:object_r:boottime_prop:s0 exact int
ro.boottime.tombstoned u:object_r:boottime_prop:s0 exact int
ro.boottime.ueventd u:object_r:boottime_prop:s0 exact int
ro.boottime.vendor.keymint-microdroid u:object_r:boottime_prop:s0 exact int
ro.boottime.zipfuse u:object_r:boottime_prop:s0 exact int
ro.build.fingerprint u:object_r:fingerprint_prop:s0 exact string
ro.vmsecret.keymint u:object_r:vmsecret_keymint_prop:s0 exact string
hwservicemanager.ready u:object_r:hwservicemanager_prop:s0 exact bool
apexd.status u:object_r:apexd_prop:s0 exact enum starting activated ready
ro.cold_boot_done u:object_r:cold_boot_done_prop:s0 exact bool
sys.usb.controller u:object_r:usb_control_prop:s0 exact string
SELinux policy for authfs_service and authfs authfs_service is a binder service on microdroid. Upon a request by the client, the service will create the mount directory, execute authfs to mount the FUSE, and finally unmount and delete the mount directory. authfs currently requires more privileges than it should, but it's ok because the client owns the VM, and all input will be verified by signatures. But there is plan to keep the privileges isoated in the service (b/195554831). Bug: 194717985 Bug: 195554831 Test: Start the service from init, use a test executable to call the service API. Only observed denial from the test executable. Change-Id: Ie53aa9e2796433fc3182357039d0b7ba1c0848ef
2021-08-04 02:26:38 +02:00
init.svc.authfs_service u:object_r:init_service_status_private_prop:s0 exact string
Move microdroid sepolicy to system/sepolicy Bug: 190511750 Test: boot microdroid Change-Id: I4aa4a56e9be5103d70469c3508110a973f3e4f12
2021-07-19 09:48:34 +02:00
init.svc.hwservicemanager u:object_r:init_service_status_private_prop:s0 exact string
init.svc.keystore2 u:object_r:init_service_status_private_prop:s0 exact string
init.svc.logd u:object_r:init_service_status_private_prop:s0 exact string
init.svc.logd-reinit u:object_r:init_service_status_private_prop:s0 exact string
init.svc.microdroid_manager u:object_r:init_service_status_private_prop:s0 exact string
init.svc.servicemanager u:object_r:init_service_status_private_prop:s0 exact string
init.svc.ueventd u:object_r:init_service_status_private_prop:s0 exact string
init.svc.zipfuse u:object_r:init_service_status_private_prop:s0 exact string
init.svc.adbd u:object_r:init_service_status_prop:s0 exact string
init.svc.tombstoned u:object_r:init_service_status_prop:s0 exact string
init.svc.vendor.keymint-microdroid u:object_r:vendor_default_prop:s0 exact string
ro.boot.hardware u:object_r:bootloader_prop:s0 exact string
ro.baseband u:object_r:bootloader_prop:s0 exact string
ro.bootloader u:object_r:bootloader_prop:s0 exact string
ro.bootmode u:object_r:bootloader_prop:s0 exact string
ro.hardware u:object_r:bootloader_prop:s0 exact string
ro.revision u:object_r:bootloader_prop:s0 exact string
ro.build.id u:object_r:build_prop:s0 exact string
ro.build.version.release u:object_r:build_prop:s0 exact string
ro.build.version.security_patch u:object_r:build_prop:s0 exact string
ro.debuggable u:object_r:build_prop:s0 exact bool
ro.product.cpu.abilist u:object_r:build_prop:s0 exact string
ro.adb.secure u:object_r:build_prop:s0 exact bool
ro.property_service.version u:object_r:property_service_version_prop:s0 exact int
ro.boot.slot_suffix u:object_r:exported_default_prop:s0 exact string
ro.apex.updatable u:object_r:exported_default_prop:s0 exact bool
keystore.boot_level u:object_r:keystore_listen_prop:s0 exact int
Microdroid boot process is controlled by microdroid_manager Previously, the boot process of microdroid was mostly implemented in the init.rc file. microdroid_manager was started first in the background, then apexd, apkdmverity, and zipfuse were executed in sequence. However, in order to correctly implement the app payload verification scheme, most of the early boot process has to be controlled by microdroid_manager. Specifically, apkdmverity should be started "after" the apk roothash is read from the instance disk by microdroid_manager. As an alternative, we could let apkdmverity the read instance disk by itself. However, this is undesirable because doing so requires multiple processes - microdroid_manager and apkdmverity - have access to the instance disk and more seriously the secret key to decrypt it. Another alternative is to let microdroid_manager do the dm-verity configuration which apkdmverity does. This also is considered undesirable because then we would give the permissions for configuring dm-verity devices to microdroid_manager which is a long-running daemon process. Note that apkdmverity is not a daemon process. This CL introduces a few number of changes which are required to let microdroid_manager directly control the early boot process: 1) microdroid_manager is allowed to start the services apkdmverity and zipfuse by using the `ctl.start` sysprop. 2) apkdmverity is allowed to use bootstrap bionic libraries as it is now executed before APEXd activates the APEXes. 3) A new sysprop `microdroid_manager.apk_roothash` is added. It is written by microdroid_manager and read by apkdmverity. It contains the roothash read from the instance disk. This value is not a secret. 4) Another new sysprop `apex_config.done` is added. It is set by init just after `perform_apex_config` and read by microdroid_manager. Microdroid_manager uses this to wait until linker configuration is ready so that it can execute app payloads with the config. Bug: 193504400 Test: atest MicrodroidHostTestCases Change-Id: If29ce17d7a6cb4859e8ceeffb321724e7f11bf82
2021-09-06 08:39:31 +02:00
apex_config.done u:object_r:apex_config_prop:s0 exact bool
microdroid_manager.apk_roothash u:object_r:microdroid_manager_roothash_prop:s0 exact string
Reference in a new issue Copy permalink