platform_system_sepolicy/public/hwservice.te

54 lines
3 KiB
Text
Raw Normal View History

type default_android_hwservice, hwservice_manager_type;
type fwk_display_hwservice, hwservice_manager_type, coredomain_hwservice;
Assert apps can access only approved HwBinder services App domains which host arbitrary code must not have access to arbitrary HwBinder services. Such access unnecessarily increases the attack surface. The reason is twofold: 1. HwBinder servers do not perform client authentication because HIDL currently does not expose caller UID information and, even if it did, many HwBinder services either operate at a layer below that of apps (e.g., HALs) or must not rely on app identity for authorization. Thus, to be safe, the default assumption is that a HwBinder service treats all its clients as equally authorized to perform operations offered by the service. 2. HAL servers (a subset of HwBinder services) contain code with higher incidence rate of security issues than system/core components and have access to lower layes of the stack (all the way down to hardware) thus increasing opportunities for bypassing the Android security model. HwBinder services offered by core components (as opposed to vendor components) are considered safer because of point #2 above. Always same-process aka always-passthrough HwBinder services are considered safe for access by these apps. This is because these HALs by definition do not offer any additional access beyond what its client already as, because these services run in the process of the client. This commit thus introduces these two categories of HwBinder services in neverallow rules. Test: mmm system/sepolicy -- this does not change on-device policy Bug: 34454312 Change-Id: I4f5f4dd10b3fc3bb9d262dda532d4a23dcdf061d
2017-04-22 02:06:43 +02:00
type fwk_scheduler_hwservice, hwservice_manager_type, coredomain_hwservice;
type fwk_sensor_hwservice, hwservice_manager_type, coredomain_hwservice;
type hal_audio_hwservice, hwservice_manager_type;
type hal_bluetooth_hwservice, hwservice_manager_type;
type hal_bootctl_hwservice, hwservice_manager_type;
type hal_broadcastradio_hwservice, hwservice_manager_type;
type hal_camera_hwservice, hwservice_manager_type;
type hal_configstore_ISurfaceFlingerConfigs, hwservice_manager_type;
type hal_contexthub_hwservice, hwservice_manager_type;
type hal_drm_hwservice, hwservice_manager_type;
type hal_cas_hwservice, hwservice_manager_type;
type hal_dumpstate_hwservice, hwservice_manager_type;
type hal_fingerprint_hwservice, hwservice_manager_type;
type hal_gatekeeper_hwservice, hwservice_manager_type;
type hal_gnss_hwservice, hwservice_manager_type;
type hal_graphics_allocator_hwservice, hwservice_manager_type;
type hal_graphics_composer_hwservice, hwservice_manager_type;
Assert apps can access only approved HwBinder services App domains which host arbitrary code must not have access to arbitrary HwBinder services. Such access unnecessarily increases the attack surface. The reason is twofold: 1. HwBinder servers do not perform client authentication because HIDL currently does not expose caller UID information and, even if it did, many HwBinder services either operate at a layer below that of apps (e.g., HALs) or must not rely on app identity for authorization. Thus, to be safe, the default assumption is that a HwBinder service treats all its clients as equally authorized to perform operations offered by the service. 2. HAL servers (a subset of HwBinder services) contain code with higher incidence rate of security issues than system/core components and have access to lower layes of the stack (all the way down to hardware) thus increasing opportunities for bypassing the Android security model. HwBinder services offered by core components (as opposed to vendor components) are considered safer because of point #2 above. Always same-process aka always-passthrough HwBinder services are considered safe for access by these apps. This is because these HALs by definition do not offer any additional access beyond what its client already as, because these services run in the process of the client. This commit thus introduces these two categories of HwBinder services in neverallow rules. Test: mmm system/sepolicy -- this does not change on-device policy Bug: 34454312 Change-Id: I4f5f4dd10b3fc3bb9d262dda532d4a23dcdf061d
2017-04-22 02:06:43 +02:00
type hal_graphics_mapper_hwservice, hwservice_manager_type, same_process_hwservice;
type hal_health_hwservice, hwservice_manager_type;
type hal_ir_hwservice, hwservice_manager_type;
type hal_keymaster_hwservice, hwservice_manager_type;
type hal_light_hwservice, hwservice_manager_type;
type hal_lowpan_hwservice, hwservice_manager_type;
type hal_memtrack_hwservice, hwservice_manager_type;
type hal_neuralnetworks_hwservice, hwservice_manager_type;
type hal_nfc_hwservice, hwservice_manager_type;
type hal_oemlock_hwservice, hwservice_manager_type;
type hal_omx_hwservice, hwservice_manager_type;
type hal_power_hwservice, hwservice_manager_type;
Assert apps can access only approved HwBinder services App domains which host arbitrary code must not have access to arbitrary HwBinder services. Such access unnecessarily increases the attack surface. The reason is twofold: 1. HwBinder servers do not perform client authentication because HIDL currently does not expose caller UID information and, even if it did, many HwBinder services either operate at a layer below that of apps (e.g., HALs) or must not rely on app identity for authorization. Thus, to be safe, the default assumption is that a HwBinder service treats all its clients as equally authorized to perform operations offered by the service. 2. HAL servers (a subset of HwBinder services) contain code with higher incidence rate of security issues than system/core components and have access to lower layes of the stack (all the way down to hardware) thus increasing opportunities for bypassing the Android security model. HwBinder services offered by core components (as opposed to vendor components) are considered safer because of point #2 above. Always same-process aka always-passthrough HwBinder services are considered safe for access by these apps. This is because these HALs by definition do not offer any additional access beyond what its client already as, because these services run in the process of the client. This commit thus introduces these two categories of HwBinder services in neverallow rules. Test: mmm system/sepolicy -- this does not change on-device policy Bug: 34454312 Change-Id: I4f5f4dd10b3fc3bb9d262dda532d4a23dcdf061d
2017-04-22 02:06:43 +02:00
type hal_renderscript_hwservice, hwservice_manager_type, same_process_hwservice;
type hal_sensors_hwservice, hwservice_manager_type;
type hal_telephony_hwservice, hwservice_manager_type;
type hal_tetheroffload_hwservice, hwservice_manager_type;
type hal_thermal_hwservice, hwservice_manager_type;
type hal_tv_cec_hwservice, hwservice_manager_type;
type hal_tv_input_hwservice, hwservice_manager_type;
type hal_usb_hwservice, hwservice_manager_type;
type hal_vibrator_hwservice, hwservice_manager_type;
type hal_vr_hwservice, hwservice_manager_type;
type hal_weaver_hwservice, hwservice_manager_type;
type hal_wifi_hwservice, hwservice_manager_type;
type hal_wifi_offload_hwservice, hwservice_manager_type;
type hal_wifi_supplicant_hwservice, hwservice_manager_type;
Assert apps can access only approved HwBinder services App domains which host arbitrary code must not have access to arbitrary HwBinder services. Such access unnecessarily increases the attack surface. The reason is twofold: 1. HwBinder servers do not perform client authentication because HIDL currently does not expose caller UID information and, even if it did, many HwBinder services either operate at a layer below that of apps (e.g., HALs) or must not rely on app identity for authorization. Thus, to be safe, the default assumption is that a HwBinder service treats all its clients as equally authorized to perform operations offered by the service. 2. HAL servers (a subset of HwBinder services) contain code with higher incidence rate of security issues than system/core components and have access to lower layes of the stack (all the way down to hardware) thus increasing opportunities for bypassing the Android security model. HwBinder services offered by core components (as opposed to vendor components) are considered safer because of point #2 above. Always same-process aka always-passthrough HwBinder services are considered safe for access by these apps. This is because these HALs by definition do not offer any additional access beyond what its client already as, because these services run in the process of the client. This commit thus introduces these two categories of HwBinder services in neverallow rules. Test: mmm system/sepolicy -- this does not change on-device policy Bug: 34454312 Change-Id: I4f5f4dd10b3fc3bb9d262dda532d4a23dcdf061d
2017-04-22 02:06:43 +02:00
type hidl_allocator_hwservice, hwservice_manager_type, coredomain_hwservice;
type hidl_base_hwservice, hwservice_manager_type;
Assert apps can access only approved HwBinder services App domains which host arbitrary code must not have access to arbitrary HwBinder services. Such access unnecessarily increases the attack surface. The reason is twofold: 1. HwBinder servers do not perform client authentication because HIDL currently does not expose caller UID information and, even if it did, many HwBinder services either operate at a layer below that of apps (e.g., HALs) or must not rely on app identity for authorization. Thus, to be safe, the default assumption is that a HwBinder service treats all its clients as equally authorized to perform operations offered by the service. 2. HAL servers (a subset of HwBinder services) contain code with higher incidence rate of security issues than system/core components and have access to lower layes of the stack (all the way down to hardware) thus increasing opportunities for bypassing the Android security model. HwBinder services offered by core components (as opposed to vendor components) are considered safer because of point #2 above. Always same-process aka always-passthrough HwBinder services are considered safe for access by these apps. This is because these HALs by definition do not offer any additional access beyond what its client already as, because these services run in the process of the client. This commit thus introduces these two categories of HwBinder services in neverallow rules. Test: mmm system/sepolicy -- this does not change on-device policy Bug: 34454312 Change-Id: I4f5f4dd10b3fc3bb9d262dda532d4a23dcdf061d
2017-04-22 02:06:43 +02:00
type hidl_manager_hwservice, hwservice_manager_type, coredomain_hwservice;
type hidl_memory_hwservice, hwservice_manager_type, coredomain_hwservice;
type hidl_token_hwservice, hwservice_manager_type, coredomain_hwservice;
type system_net_netd_hwservice, hwservice_manager_type, coredomain_hwservice;
Assert apps can access only approved HwBinder services App domains which host arbitrary code must not have access to arbitrary HwBinder services. Such access unnecessarily increases the attack surface. The reason is twofold: 1. HwBinder servers do not perform client authentication because HIDL currently does not expose caller UID information and, even if it did, many HwBinder services either operate at a layer below that of apps (e.g., HALs) or must not rely on app identity for authorization. Thus, to be safe, the default assumption is that a HwBinder service treats all its clients as equally authorized to perform operations offered by the service. 2. HAL servers (a subset of HwBinder services) contain code with higher incidence rate of security issues than system/core components and have access to lower layes of the stack (all the way down to hardware) thus increasing opportunities for bypassing the Android security model. HwBinder services offered by core components (as opposed to vendor components) are considered safer because of point #2 above. Always same-process aka always-passthrough HwBinder services are considered safe for access by these apps. This is because these HALs by definition do not offer any additional access beyond what its client already as, because these services run in the process of the client. This commit thus introduces these two categories of HwBinder services in neverallow rules. Test: mmm system/sepolicy -- this does not change on-device policy Bug: 34454312 Change-Id: I4f5f4dd10b3fc3bb9d262dda532d4a23dcdf061d
2017-04-22 02:06:43 +02:00
type system_wifi_keystore_hwservice, hwservice_manager_type, coredomain_hwservice;
type thermalcallback_hwservice, hwservice_manager_type;