1# only HALs responsible for network hardware should have privileged 2# network capabilities 3neverallow { 4 halserverdomain 5 -hal_bluetooth_server 6 -hal_wifi_server 7 -hal_wifi_supplicant_server 8 -rild 9} self:capability { net_admin net_raw }; 10 11# Unless a HAL's job is to communicate over the network, or control network 12# hardware, it should not be using network sockets. 13neverallow { 14 halserverdomain 15 -hal_tetheroffload_server 16 -hal_wifi_server 17 -hal_wifi_supplicant_server 18 -rild 19} domain:{ tcp_socket udp_socket rawip_socket } *; 20 21### 22# HALs are defined as an attribute and so a given domain could hypothetically 23# have multiple HALs in it (or even all of them) with the subsequent policy of 24# the domain comprised of the union of all the HALs. 25# 26# This is a problem because 27# 1) Security sensitive components should only be accessed by specific HALs. 28# 2) hwbinder_call and the restrictions it provides cannot be reasoned about in 29# the platform. 30# 3) The platform cannot reason about defense in depth if there are 31# monolithic domains etc. 32# 33# As an example, hal_keymaster and hal_gatekeeper can access the TEE and while 34# its OK for them to share a process its not OK with them to share processes 35# with other hals. 36# 37# The following neverallow rules, in conjuntion with CTS tests, assert that 38# these security principles are adhered to. 39# 40# Do not allow a hal to exec another process without a domain transition. 41# TODO remove exemptions. 42neverallow { 43 halserverdomain 44 -hal_dumpstate_server 45 -rild 46} { file_type fs_type }:file execute_no_trans; 47# Do not allow a process other than init to transition into a HAL domain. 48neverallow { domain -init } halserverdomain:process transition; 49# Only allow transitioning to a domain by running its executable. Do not 50# allow transitioning into a HAL domain by use of seclabel in an 51# init.*.rc script. 52neverallow * halserverdomain:process dyntransition; 53