1# System and vendor domains for BoringSSL self test binaries. 2# 3# For FIPS compliance, all processes linked against libcrypto perform a startup 4# self test which computes a hash of the BoringSSL Crypto Module (BCM) and, at least once 5# per device boot, also run a series of Known Answer Tests (KAT) to verify functionality. 6# 7# The KATs are expensive, and to ensure they are run as few times as possible, they 8# are skipped if a marker file exists in /dev/boringssl/selftest whose name is 9# the hash of the BCM that was computed earlier. The files are zero length and their contents 10# should never be read or written. To avoid giving arbitrary processes access to /dev/boringssl 11# to create these marker files, there are dedicated self test binaries which this policy 12# gives access to and which are run during early-init. 13# 14# Due to build skew, the version of libcrypto in /vendor may have a different hash than 15# the system one. To cater for this there are vendor variants of the self test binaries 16# which also have permission to write to the same files in /dev/boringssl. In the case where 17# vendor and system libcrypto have the same hash, there will be a race to create the file, 18# but this is harmless. 19# 20# If the self tests fail, then the device should reboot into firmware and for this reason 21# the system boringssl_self_test domain needs to be in coredomain. As vendor domains 22# are not allowed in coredomain, this means that the vendor self tests cannot trigger a 23# reboot. However every binary linked against the vendor libcrypto will abort on startup, 24# so in practice the device will crash anyway in this unlikely scenario. 25 26# System boringssl_self_test domain 27type boringssl_self_test, domain, coredomain; 28type boringssl_self_test_exec, system_file_type, exec_type, file_type; 29 30# Vendor boringssl_self_test domain 31type vendor_boringssl_self_test, domain; 32type vendor_boringssl_self_test_exec, vendor_file_type, exec_type, file_type; 33 34# Switch to boringssl_self_test security domain when running boringssl_self_test_exec 35init_daemon_domain(boringssl_self_test) 36 37# Switch to vendor_boringssl_self_test security domain when running vendor_boringssl_self_test_exec 38init_daemon_domain(vendor_boringssl_self_test) 39 40# Marker files, common to both domains, indicating KAT have been performed on a particular libcrypto 41# 42# The files are zero length so there is no issue if both vendor and system code 43# try to create the same file simultaneously. One will succeed and the other will fail 44# silently, i.e. still indicate success. Similar harmless naming collisions will happen in the 45# system domain e.g. when system and APEX copies of libcrypto are identical. 46type boringssl_self_test_marker, file_type; 47 48# Allow self test binaries to create/check for the existence of boringssl_self_test_marker files 49allow { boringssl_self_test vendor_boringssl_self_test } 50 boringssl_self_test_marker:file create_file_perms; 51allow { boringssl_self_test vendor_boringssl_self_test } 52 boringssl_self_test_marker:dir ra_dir_perms; 53 54# Allow self test binaries to write their stdout/stderr messages to kmsg_debug 55allow { boringssl_self_test vendor_boringssl_self_test } 56 kmsg_debug_device:chr_file { w_file_perms getattr ioctl }; 57 58# No other process should be able to create marker files because their existence causes the 59# boringssl KAT to be skipped. 60neverallow { 61 domain 62 -vendor_boringssl_self_test 63 -boringssl_self_test 64 -init 65 -vendor_init 66} boringssl_self_test_marker:file no_rw_file_perms; 67 68neverallow { 69 domain 70 -vendor_boringssl_self_test 71 -boringssl_self_test 72 -init 73 -vendor_init 74} boringssl_self_test_marker:dir write; 75