Select Git revision
hal_neverallows.te
Jeff Vander Stoep
authored and
android-build-team Robot
committed
Due to the massively increased number of attributes in SELinux policy
as part of the treble changes, we have had to remove attributes from
policy for performance reasons. Unfortunately, some attributes are
required to be in policy to ensure that our neverallow rules are being
properly enforced. Usually this is not a problem, since neverallow rules
indicate that an attribute should be kept, but this is not currently the
case when the attribute is part of a negation in a group.
This is particularly problematic with treble since some attributes may
exist for HALs that have no implementation, and thus no types. In
particular, this has caused an issue with the neverallows added in our
macros. Add an extraneous neverallow rule to each of those auto-generated
neverallow rules to make sure that they are not removed from policy, until
the policy compiler is fixed to avoid this. Also add corresponding rules
for other types which have been removed due to no corresponding rules.
Bug: 62658302
Bug: 62999603
Test: Build Marlin policy.
Test: verify attribute exists in policy using sepolicy-analyze.
sepolicy-analyze $OUT/vendor/etc/selinux/precompiled_sepolicy \
attribute hal_tetheroffload_server
Test: CTS neverallow tests pass.
cts-tradefed run cts -m CtsSecurityHostTestCases -t \
android.cts.security.SELinuxNeverallowRulesTest
Change-Id: I62596ba8198ffdcbb4315df639a834e4becaf249
(cherry picked from commit c75aa50d) hal_neverallows.te 1.96 KiB
# only HALs responsible for network hardware should have privileged
# network capabilities
neverallow {
halserverdomain
-hal_bluetooth_server
-hal_wifi_server
-hal_wifi_supplicant_server
-rild
} self:capability { net_admin net_raw };
# Unless a HAL's job is to communicate over the network, or control network
# hardware, it should not be using network sockets.
neverallow {
halserverdomain
-hal_tetheroffload_server
-hal_wifi_server
-hal_wifi_supplicant_server
-rild
} domain:{ tcp_socket udp_socket rawip_socket } *;
neverallow hal_tetheroffload_server unlabeled:service_manager list; #TODO: b/62658302
###
# 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
-rild
} { 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;