blob: 0214e2ae66de0755ce8479fd67065ca7e24671aa [file] [log] [blame]
Jeff Vander Stoepf9be7652017-03-13 13:32:51 -07001# only HALs responsible for network hardware should have privileged
2# network capabilities
3neverallow {
4 halserverdomain
5 -hal_bluetooth_server
Tomasz Wasilczyk602b3032019-07-23 17:38:51 -07006 -hal_can_controller_server
Jeff Vander Stoepf9be7652017-03-13 13:32:51 -07007 -hal_wifi_server
Roshan Piusd7b34a42017-12-22 15:03:15 -08008 -hal_wifi_hostapd_server
Jeff Vander Stoepf9be7652017-03-13 13:32:51 -07009 -hal_wifi_supplicant_server
Amit Mahajan30073442018-03-12 17:12:09 +000010 -hal_telephony_server
Benjamin Gordon9b2e0cb2017-11-09 15:51:26 -070011} self:global_capability_class_set { net_admin net_raw };
Jeff Vander Stoepf9be7652017-03-13 13:32:51 -070012
Jeff Vander Stoepd75a2c02017-06-21 12:46:21 -070013# Unless a HAL's job is to communicate over the network, or control network
14# hardware, it should not be using network sockets.
Pavel Maltsev8d7f5032018-05-15 14:16:57 -070015# NOTE: HALs for automotive devices have an exemption from this rule because in
16# a car it is common to have external modules and HALs need to communicate to
17# those modules using network. Using this exemption for non-automotive builds
18# will result in CTS failure.
Jeff Vander Stoepf9be7652017-03-13 13:32:51 -070019neverallow {
20 halserverdomain
Pavel Maltsev8d7f5032018-05-15 14:16:57 -070021 -hal_automotive_socket_exemption
Tomasz Wasilczyk602b3032019-07-23 17:38:51 -070022 -hal_can_controller_server
Jeff Vander Stoepd75a2c02017-06-21 12:46:21 -070023 -hal_tetheroffload_server
Jeff Vander Stoepf9be7652017-03-13 13:32:51 -070024 -hal_wifi_server
Roshan Piusd7b34a42017-12-22 15:03:15 -080025 -hal_wifi_hostapd_server
Jeff Vander Stoepf9be7652017-03-13 13:32:51 -070026 -hal_wifi_supplicant_server
Amit Mahajan30073442018-03-12 17:12:09 +000027 -hal_telephony_server
Yifan Hongbe04b092021-06-07 12:37:31 -070028} domain:{ udp_socket rawip_socket } *;
29
30neverallow {
31 halserverdomain
32 -hal_automotive_socket_exemption
33 -hal_can_controller_server
34 -hal_tetheroffload_server
35 -hal_wifi_server
36 -hal_wifi_hostapd_server
37 -hal_wifi_supplicant_server
38 -hal_telephony_server
39} {
40 domain
41 userdebug_or_eng(`-su')
42}:tcp_socket *;
Jeff Vander Stoep84b96a62017-03-20 14:52:58 -070043
44###
45# HALs are defined as an attribute and so a given domain could hypothetically
46# have multiple HALs in it (or even all of them) with the subsequent policy of
47# the domain comprised of the union of all the HALs.
48#
49# This is a problem because
50# 1) Security sensitive components should only be accessed by specific HALs.
51# 2) hwbinder_call and the restrictions it provides cannot be reasoned about in
52# the platform.
53# 3) The platform cannot reason about defense in depth if there are
54# monolithic domains etc.
55#
56# As an example, hal_keymaster and hal_gatekeeper can access the TEE and while
57# its OK for them to share a process its not OK with them to share processes
58# with other hals.
59#
60# The following neverallow rules, in conjuntion with CTS tests, assert that
61# these security principles are adhered to.
62#
63# Do not allow a hal to exec another process without a domain transition.
64# TODO remove exemptions.
65neverallow {
66 halserverdomain
67 -hal_dumpstate_server
Amit Mahajan30073442018-03-12 17:12:09 +000068 -hal_telephony_server
Jeff Vander Stoep84b96a62017-03-20 14:52:58 -070069} { file_type fs_type }:file execute_no_trans;
70# Do not allow a process other than init to transition into a HAL domain.
71neverallow { domain -init } halserverdomain:process transition;
72# Only allow transitioning to a domain by running its executable. Do not
73# allow transitioning into a HAL domain by use of seclabel in an
74# init.*.rc script.
75neverallow * halserverdomain:process dyntransition;