odsign: 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 the capabilities that composd needs.
The list of capabilities that odsign is allowed to use was obtained via:
```
$ adb pull /sys/fs/selinux/policy /tmp/selinux.policy
$ sesearch --allow -s odsign -c capability,capability2 /tmp/selinux.policy
```
Note: odsign can also transition in several domains, but none of them
seem to require any capabilities as well:
```
$ sesearch --allow -s compos_verify -c capability,capability2 /tmp/selinux.policy
$ sesearch --allow -s odrefresh -c capability,capability2 /tmp/selinux.policy
$ sesearch --allow -s fsverity_init -c capability,capability2 /tmp/selinux.policy
```
Bug: 249796710
Test: atest odsign_e2e_tests_full
Test: presubmit
Change-Id: I01b52d2510575a8c6912476c8229c682f35e0835
diff --git a/ondevice-signing/odsign.rc b/ondevice-signing/odsign.rc
index de09fc0..b96c62f 100644
--- a/ondevice-signing/odsign.rc
+++ b/ondevice-signing/odsign.rc
@@ -3,6 +3,13 @@
user root
group system
disabled # does not start with the core class
+ # Explicitly specify empty capabilities, otherwise odsign will inherit all
+ # the capabilities from init.
+ # Note: whether a process can use capabilities is controlled by SELinux, so
+ # inheriting all the capabilities from init is not a security issue.
+ # However, for defense-in-depth and just for the sake of bookkeeping it's
+ # better to explicitly state that odsign doesn't need any capabilities.
+ capabilities
# Note that odsign is not oneshot, but stopped manually when it exits. This
# ensures that if odsign crashes during a module update, apexd will detect