sepolicy: allow init to share a kallsyms fd with tracing daemons
See r.android.com/3408241 for context.
The new order of operations in init:
1) open /proc/kallsyms while it is allowed to see the raw addresses,
which becomes a property of that fd. The fd is retained.
2) Raise kptr_restrict to 2, masking out addresses for all future opens
of /proc/kallsyms, including by init itself. This happens before
the "early-init" stage.
3) Share duplicates of the original saved fd with tracing daemons when
they're started.
The two daemons are still allowed to open their own copies of
/proc/kallsyms to facilitate file locks to coordinate access to the
shared fd (which cannot be used for locking as all processes will share
the lock as well). These opens are harmless since they couldn't give
more info than the fd shared by init (and in practice, the addresses
will be masked out due to kptr_restrict=2).
I've removed the neverallow exclusion for vendor_init since I believe
there wasn't a concrete use-case when it was first added, and it does
not participate in this new fd sharing.
Bug: 383513654
Change-Id: Ie2ab26da6186524bc77cd99bb55a61cef4a7ddf4
diff --git a/private/init.te b/private/init.te
index b16e918..c3899e1 100644
--- a/private/init.te
+++ b/private/init.te
@@ -68,6 +68,12 @@
allow init self:perf_event { open cpu };
allow init self:global_capability2_class_set perfmon;
+# Allow opening /proc/kallsyms so that on boot, init can create and retain an
+# fd with the full address visibility (which is evaluated on open and persists
+# for the lifetime of the open file description). This fd can then be shared
+# with other privileged processes.
+allow init proc_kallsyms:file r_file_perms;
+
# Allow init to communicate with snapuserd to transition Virtual A/B devices
# from the first-stage daemon to the second-stage.
allow init snapuserd_socket:sock_file write;