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/vendor_init.te b/private/vendor_init.te
index a50bc27..60962d4 100644
--- a/private/vendor_init.te
+++ b/private/vendor_init.te
@@ -116,6 +116,7 @@
   -aconfig_storage_metadata_file
   -aconfig_storage_flags_metadata_file
   -tradeinmode_metadata_file
+  -proc_kallsyms
   enforce_debugfs_restriction(`-debugfs_type')
 }:file { create getattr open read write setattr relabelfrom unlink map };
 
@@ -195,6 +196,7 @@
   -proc_uid_time_in_state
   -proc_uid_concurrent_active_time
   -proc_uid_concurrent_policy_time
+  -proc_kallsyms
   enforce_debugfs_restriction(`-debugfs_type')
 }:file { open read setattr map };