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