platform_system_sepolicy/private/remote_prov_app.te

type remote_prov_app, domain;
typeattribute remote_prov_app coredomain;

app_domain(remote_prov_app)
net_domain(remote_prov_app)

get_prop(remote_prov_app, remote_prov_prop)
# The app needs access to properly build a DeviceInfo package for the verifying server
get_prop(remote_prov_app, vendor_security_patch_level_prop)

allow remote_prov_app {
    app_api_service
    remoteprovisioning_service
}:service_manager find;
SEPolicy for RemoteProvisioning App This change adds the SEPolicy changes required to support the remote provisioning flow. The notable additions are specifically labeling the remote provisioning app and giving it access to find the remote provisioning service which is added in keystore. It also requires network access in order to communicate to the provisioning servers. This functionality is extremely narrow to the point that it seems worth it to define a separate domain for this app, rather than add this in to the priv_app or platform_app permission files. Since this app also communicates with the network, it also seems advantageous to limit its permissions only to what is absolutely necessary to perform its function. Test: No denials! Change-Id: I602c12365a575d914afc91f55e6a9b6aa2e14189 2020-12-24 06:53:08 +01:00			`type remote_prov_app, domain;`
			`typeattribute remote_prov_app coredomain;`

			`app_domain(remote_prov_app)`
			`net_domain(remote_prov_app)`

Add ro.remote_provisioning.*.rkp_only properties. These properties are used to inform keystore2 and the RemoteProvisioner app how they should behave in the system in the event that RKP keys are exhausted. The usual behavior in a hybrid system is not to take any action and fallback to the factory provisioned key if key attestation is requested and no remotely provisioned keys are available. However, there are instances where this could happen on a device that was intended to be RKP only, in which case the system needs to know that it should go ahead and attempt to remotely provision new certificates or throw an error in the case where none are available. Test: New properties are accessible from the two domains Change-Id: I8d6c9e650566499bf08cfda2f71c64d5c2b26fd6 2022-02-02 06:15:44 +01:00			`get_prop(remote_prov_app, remote_prov_prop)`
Granting remote_prov_app access to build prop The RemoteProvisioner app builds a DeviceInfo CBOR object which is eventually used as AAD to verify the authenticity of a signed MAC key in the remote provisioning spec. One of those fields is vendor security patch level, which this patch grants access for the remote_prov_app domain to read. Test: No denials! (atest RemoteProvisionerUnitTests) Change-Id: Iab0426fb5ec184cda171d67451bf44cae897bf9b 2021-02-22 11:07:01 +01:00			`# The app needs access to properly build a DeviceInfo package for the verifying server`
			`get_prop(remote_prov_app, vendor_security_patch_level_prop)`

SEPolicy for RemoteProvisioning App This change adds the SEPolicy changes required to support the remote provisioning flow. The notable additions are specifically labeling the remote provisioning app and giving it access to find the remote provisioning service which is added in keystore. It also requires network access in order to communicate to the provisioning servers. This functionality is extremely narrow to the point that it seems worth it to define a separate domain for this app, rather than add this in to the priv_app or platform_app permission files. Since this app also communicates with the network, it also seems advantageous to limit its permissions only to what is absolutely necessary to perform its function. Test: No denials! Change-Id: I602c12365a575d914afc91f55e6a9b6aa2e14189 2020-12-24 06:53:08 +01:00			`allow remote_prov_app {`
Allow remote_prov_app to find app_api_service Due to the nature of RemoteProvisioner being an app, there are many components under the hood of frameworks that make calls out to standard app available services. This change allows remote_prov_app to find any service labeled with app_api_service to avoid the brittleness that has already arisen from generating SELinux denials on boot, and avoid any potential unintended functionality consequences as a result of those. Test: No selinux denials Change-Id: I95fc4d15a196646deb6b9f6040bac88ee00b2a7f 2021-03-23 21:55:14 +01:00			`app_api_service`
SEPolicy for RemoteProvisioning App This change adds the SEPolicy changes required to support the remote provisioning flow. The notable additions are specifically labeling the remote provisioning app and giving it access to find the remote provisioning service which is added in keystore. It also requires network access in order to communicate to the provisioning servers. This functionality is extremely narrow to the point that it seems worth it to define a separate domain for this app, rather than add this in to the priv_app or platform_app permission files. Since this app also communicates with the network, it also seems advantageous to limit its permissions only to what is absolutely necessary to perform its function. Test: No denials! Change-Id: I602c12365a575d914afc91f55e6a9b6aa2e14189 2020-12-24 06:53:08 +01:00			`remoteprovisioning_service`
			`}:service_manager find;`