1 # only HALs responsible for network hardware should have privileged 2 # network capabilities 3 neverallow { 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. 13 neverallow { 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. 42 neverallow { 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. 48 neverallow { 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. 52 neverallow * halserverdomain:process dyntransition; 53
