boringssl self tests: explicitly specify empty capabilities
If a service doesn't specify any capabilities in it's definition in the
.rc file, then it will inherit all the capabilities from the init.
Although whether a process can use capabilities is actually controlled
by selinux (so inheriting all the init capabilities is not actually a
security vulnerability), it's better for defense-in-depth and just
bookkeeping to explicitly specify that boringssl_self_test doesn't need
any capabilities
The list of capabilities was obtained via:
```
$ adb pull /sys/fs/selinux/policy /tmp/selinux.policy
$ sesearch --allow -s boringssl_self_test -c capability,capability2 /tmp/selinux.policy
```
Bug: 249796710
Test: device boots
Test: presubmit
Change-Id: I866222e2325e59d7e39d00db59df7b83efc657d9
diff --git a/rootdir/init.rc b/rootdir/init.rc
index 55be31a..323d9cb 100644
--- a/rootdir/init.rc
+++ b/rootdir/init.rc
@@ -490,18 +490,26 @@
service boringssl_self_test32 /system/bin/boringssl_self_test32
reboot_on_failure reboot,boringssl-self-check-failed
stdio_to_kmsg
+ # Explicitly specify that boringssl_self_test32 doesn't require any capabilities
+ capabilities
service boringssl_self_test64 /system/bin/boringssl_self_test64
reboot_on_failure reboot,boringssl-self-check-failed
stdio_to_kmsg
+ # Explicitly specify that boringssl_self_test64 doesn't require any capabilities
+ capabilities
service boringssl_self_test_apex32 /apex/com.android.conscrypt/bin/boringssl_self_test32
reboot_on_failure reboot,boringssl-self-check-failed
stdio_to_kmsg
+ # Explicitly specify that boringssl_self_test_apex32 doesn't require any capabilities
+ capabilities
service boringssl_self_test_apex64 /apex/com.android.conscrypt/bin/boringssl_self_test64
reboot_on_failure reboot,boringssl-self-check-failed
stdio_to_kmsg
+ # Explicitly specify that boringssl_self_test_apex64 doesn't require any capabilities
+ capabilities
# Healthd can trigger a full boot from charger mode by signaling this