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
To aid in debugging if there are failures.
Bug: 137267623
Test: add prints to boringssl_self_test and see them
Change-Id: I34b20225514898911b3f476d4517430433eb379e
This reverts commit a9b718a1ed.
Reason for revert: No longer be necessary after
http://r.android.com/1120246 lands as this causes BoringSSL to only write
flag files if a particular environment variable is set, and this variable
will only be set for the self test binaries which have permission to
write to /dev/boringssl.
Bug: 140918050
Test: Manually observed audit log after change
Change-Id: I851f4aea991d91c67b64535829eea5b9594a3e2c
Binaries other than boringssl_self_test_exec are not allowed
to create marker files /dev/boringssl/selftest/[hash].
Right now, some processes still attempt to because:
- Some binaries run so early during early-init that
boringssl_self_test{32,64} hasn't had a chance to
run yet, so the marker file doesn't exist yet, so
the unprivileged process attempts to create it.
- Some binaries statically link libcrypto so their
[hash] is different from that used by
boringssl_self_test{32,64}.
There's some ongoing work to stop those binaries even
attempting to create the marker files but it's not a
big deal if they do. Similarly, there is ongoing work
to minimize or eliminate static linking of this library.
For now, this CL turns off audit logs for this behavior
since it is harmless (a cosmetic issue) and in order to
not hold up the bulk of the logic being submitted.
Bug: 137267623
Test: Treehugger
Change-Id: I3de664c5959efd130f761764fe63515795ea9b98
Include coredomain in initial definition of boringssl_self_test
rather than adding it later. This addresses an outstanding review
comment from http://r.android.com/1110523
Test: Treehugger
Bug: 137267623
Change-Id: I4e8d4e2e76b1c3a9b5a1f806e43e885b51cb7a60
This CL adds hand-written SELinux rules to:
- define the boringssl_self_test security domain
- label the corresponding files at type boringssl_self_test_marker
and boringssl_self_test_exec.
- define an automatic transition from init to boringssl_self_test
domains, plus appropriate access permissions.
Bug: 137267623
Test: When run together with the other changes from draft CL topic
http://aosp/q/topic:bug137267623_bsslselftest, check that:
- both /dev/boringssl/selftest/* marker files are
present after the device boots.
- Test: after the boringssl_self_test{32,64} binaries have
run, no further SELinux denials occur for processes
trying to write the marker file.
Change-Id: I77de0bccdd8c1e22c354d8ea146e363f4af7e36f
