SEPolicy changes to allow vendor BoringSSL self test.
Introduces new domain vendor_boringssl_self_test and runs
/vendor/bin/boringssl_self_test(32|64) in it. New domain
required because boringssl_self_test needs to be in
coredomain in order to reboot the device, but vendor code
may not run in coredomain.
Bug: 141150335
Test: flashall && manually verify no selinux errors logged and that
four flag files are created in /dev/boringssl, two by the
system self tests and two by the vendor.
Change-Id: I46e2a5ea338eddacdfd089f696295dbd16795c5a
diff --git a/private/boringssl_self_test.te b/private/boringssl_self_test.te
index 4e2d848..50fc1fc 100644
--- a/private/boringssl_self_test.te
+++ b/private/boringssl_self_test.te
@@ -1,22 +1,65 @@
+# System and vendor domains for BoringSSL self test binaries.
+#
+# For FIPS compliance, all processes linked against libcrypto perform a startup
+# self test which computes a hash of the BoringSSL Crypto Module (BCM) and, at least once
+# per device boot, also run a series of Known Answer Tests (KAT) to verify functionality.
+#
+# The KATs are expensive, and to ensure they are run as few times as possible, they
+# are skipped if a marker file exists in /dev/boringssl/selftest whose name is
+# the hash of the BCM that was computed earlier. The files are zero length and their contents
+# should never be read or written. To avoid giving arbitrary processes access to /dev/boringssl
+# to create these marker files, there are dedicated self test binaries which this policy
+# gives access to and which are run during early-init.
+#
+# Due to build skew, the version of libcrypto in /vendor may have a different hash than
+# the system one. To cater for this there are vendor variants of the self test binaries
+# which also have permission to write to the same files in /dev/boringssl. In the case where
+# vendor and system libcrypto have the same hash, there will be a race to create the file,
+# but this is harmless.
+#
+# If the self tests fail, then the device should reboot into firmware and for this reason
+# the system boringssl_self_test domain needs to be in coredomain. As vendor domains
+# are not allowed in coredomain, this means that the vendor self tests cannot trigger a
+# reboot. However every binary linked against the vendor libcrypto will abort on startup,
+# so in practice the device will crash anyway in this unlikely scenario.
+
+# System boringssl_self_test domain
type boringssl_self_test, domain, coredomain;
type boringssl_self_test_exec, system_file_type, exec_type, file_type;
-type boringssl_self_test_marker, file_type;
-# switch to boringssl_self_test security domain when running boringssl_self_test_exec from init.
+# Vendor boringssl_self_test domain
+type vendor_boringssl_self_test, domain;
+type vendor_boringssl_self_test_exec, vendor_file_type, exec_type, file_type;
+
+# Switch to boringssl_self_test security domain when running boringssl_self_test_exec
init_daemon_domain(boringssl_self_test)
-# Allow boringssl_self_test binaries to create/check for the existence of boringssl_self_test_marker
-# files.
-allow boringssl_self_test boringssl_self_test_marker:file create_file_perms;
-allow boringssl_self_test boringssl_self_test_marker:dir ra_dir_perms;
+# Switch to vendor_boringssl_self_test security domain when running vendor_boringssl_self_test_exec
+init_daemon_domain(vendor_boringssl_self_test)
-# Allow boringsself_self_test to write its stdout/stderr messages to kmsg_debug.
-allow boringssl_self_test kmsg_debug_device:chr_file { w_file_perms getattr ioctl };
+# Marker files, common to both domains, indicating KAT have been performed on a particular libcrypto
+#
+# The files are zero length so there is no issue if both vendor and system code
+# try to create the same file simultaneously. One will succeed and the other will fail
+# silently, i.e. still indicate success. Similar harmless naming collisions will happen in the
+# system domain e.g. when system and APEX copies of libcrypto are identical.
+type boringssl_self_test_marker, file_type;
-# No other process should be able to create these files because their existence causes the
-# boringssl self test to be skipped.
+# Allow self test binaries to create/check for the existence of boringssl_self_test_marker files
+allow { boringssl_self_test vendor_boringssl_self_test }
+ boringssl_self_test_marker:file create_file_perms;
+allow { boringssl_self_test vendor_boringssl_self_test }
+ boringssl_self_test_marker:dir ra_dir_perms;
+
+# Allow self test binaries to write their stdout/stderr messages to kmsg_debug
+allow { boringssl_self_test vendor_boringssl_self_test }
+ kmsg_debug_device:chr_file { w_file_perms getattr ioctl };
+
+# No other process should be able to create marker files because their existence causes the
+# boringssl KAT to be skipped.
neverallow {
domain
+ -vendor_boringssl_self_test
-boringssl_self_test
-init
-vendor_init
@@ -24,6 +67,7 @@
neverallow {
domain
+ -vendor_boringssl_self_test
-boringssl_self_test
-init
-vendor_init
diff --git a/private/compat/29.0/29.0.ignore.cil b/private/compat/29.0/29.0.ignore.cil
index 4257087..1610bf4 100644
--- a/private/compat/29.0/29.0.ignore.cil
+++ b/private/compat/29.0/29.0.ignore.cil
@@ -23,6 +23,7 @@
system_group_file
system_passwd_file
vendor_apex_file
+ vendor_boringssl_self_test
virtual_ab_prop
wifi_stack
wifi_stack_service
diff --git a/private/file_contexts b/private/file_contexts
index ef4f2c7..cf4c69b 100644
--- a/private/file_contexts
+++ b/private/file_contexts
@@ -360,6 +360,7 @@
/vendor/apex(/[^/]+){0,2} u:object_r:vendor_apex_file:s0
/vendor/bin/misc_writer u:object_r:vendor_misc_writer_exec:s0
+/vendor/bin/boringssl_self_test(32|64) u:object_r:vendor_boringssl_self_test_exec:s0
# HAL location
/(vendor|system/vendor)/lib(64)?/hw u:object_r:vendor_hal_file:s0