2017-03-13 21:32:51 +01:00
|
|
|
# only HALs responsible for network hardware should have privileged
|
|
|
|
# network capabilities
|
|
|
|
neverallow {
|
|
|
|
halserverdomain
|
|
|
|
-hal_bluetooth_server
|
|
|
|
-hal_wifi_server
|
2017-12-23 00:03:15 +01:00
|
|
|
-hal_wifi_hostapd_server
|
2017-03-13 21:32:51 +01:00
|
|
|
-hal_wifi_supplicant_server
|
2018-03-12 18:12:09 +01:00
|
|
|
-hal_telephony_server
|
2017-11-09 23:51:26 +01:00
|
|
|
} self:global_capability_class_set { net_admin net_raw };
|
2017-03-13 21:32:51 +01:00
|
|
|
|
2017-06-21 21:46:21 +02:00
|
|
|
# Unless a HAL's job is to communicate over the network, or control network
|
|
|
|
# hardware, it should not be using network sockets.
|
2018-05-15 23:16:57 +02:00
|
|
|
# NOTE: HALs for automotive devices have an exemption from this rule because in
|
|
|
|
# a car it is common to have external modules and HALs need to communicate to
|
|
|
|
# those modules using network. Using this exemption for non-automotive builds
|
|
|
|
# will result in CTS failure.
|
2017-03-13 21:32:51 +01:00
|
|
|
neverallow {
|
|
|
|
halserverdomain
|
2018-05-15 23:16:57 +02:00
|
|
|
-hal_automotive_socket_exemption
|
2017-06-21 21:46:21 +02:00
|
|
|
-hal_tetheroffload_server
|
2017-03-13 21:32:51 +01:00
|
|
|
-hal_wifi_server
|
2017-12-23 00:03:15 +01:00
|
|
|
-hal_wifi_hostapd_server
|
2017-03-13 21:32:51 +01:00
|
|
|
-hal_wifi_supplicant_server
|
2018-03-12 18:12:09 +01:00
|
|
|
-hal_telephony_server
|
2017-03-13 21:32:51 +01:00
|
|
|
} domain:{ tcp_socket udp_socket rawip_socket } *;
|
2017-03-20 22:52:58 +01:00
|
|
|
|
|
|
|
###
|
|
|
|
# HALs are defined as an attribute and so a given domain could hypothetically
|
|
|
|
# have multiple HALs in it (or even all of them) with the subsequent policy of
|
|
|
|
# the domain comprised of the union of all the HALs.
|
|
|
|
#
|
|
|
|
# This is a problem because
|
|
|
|
# 1) Security sensitive components should only be accessed by specific HALs.
|
|
|
|
# 2) hwbinder_call and the restrictions it provides cannot be reasoned about in
|
|
|
|
# the platform.
|
|
|
|
# 3) The platform cannot reason about defense in depth if there are
|
|
|
|
# monolithic domains etc.
|
|
|
|
#
|
|
|
|
# As an example, hal_keymaster and hal_gatekeeper can access the TEE and while
|
|
|
|
# its OK for them to share a process its not OK with them to share processes
|
|
|
|
# with other hals.
|
|
|
|
#
|
|
|
|
# The following neverallow rules, in conjuntion with CTS tests, assert that
|
|
|
|
# these security principles are adhered to.
|
|
|
|
#
|
|
|
|
# Do not allow a hal to exec another process without a domain transition.
|
|
|
|
# TODO remove exemptions.
|
|
|
|
neverallow {
|
|
|
|
halserverdomain
|
|
|
|
-hal_dumpstate_server
|
2018-03-12 18:12:09 +01:00
|
|
|
-hal_telephony_server
|
2017-03-20 22:52:58 +01:00
|
|
|
} { file_type fs_type }:file execute_no_trans;
|
|
|
|
# Do not allow a process other than init to transition into a HAL domain.
|
|
|
|
neverallow { domain -init } halserverdomain:process transition;
|
|
|
|
# Only allow transitioning to a domain by running its executable. Do not
|
|
|
|
# allow transitioning into a HAL domain by use of seclabel in an
|
|
|
|
# init.*.rc script.
|
|
|
|
neverallow * halserverdomain:process dyntransition;
|