platform_system_sepolicy/private/netd.te
Maciej Żenczykowski b13921c3f0 much more finegrained bpf selinux privs for networking mainline
Goal is to gain a better handle on who has access to which maps
and to allow (with bpfloader changes to create in one directory
and move into the target directory) per-map selection of
selinux context, while still having reasonable defaults for stuff
pinned directly into the target location.

BPFFS (ie. /sys/fs/bpf) labelling is as follows:
  subdirectory   selinux context      mainline  usecase / usable by
  /              fs_bpf               no (*)    core operating system (ie. platform)
  /net_private   fs_bpf_net_private   yes, T+   network_stack
  /net_shared    fs_bpf_net_shared    yes, T+   network_stack & system_server
  /netd_readonly fs_bpf_netd_readonly yes, T+   network_stack & system_server & r/o to netd
  /netd_shared   fs_bpf_netd_shared   yes, T+   network_stack & system_server & netd [**]
  /tethering     fs_bpf_tethering     yes, S+   network_stack
  /vendor        fs_bpf_vendor        no, T+    vendor

* initial support for bpf was added back in P,
  but things worked differently back then with no bpfloader,
  and instead netd doing stuff by hand,
  bpfloader with pinning into /sys/fs/bpf was (I believe) added in Q
  (and was definitely there in R)

** additionally bpf programs are accesible to netutils_wrapper
   for use by iptables xt_bpf extensions

'mainline yes' currently means shipped by the com.android.tethering apex,
but this is really another case of bad naming, as it's really
the 'networking/connectivity/tethering' apex / mainline module.
Long term the plan is to merge a few other networking mainline modules
into it (and maybe give it a saner name...).

The reason for splitting net_private vs tethering is that:
  S+ must support 4.9+ kernels and S era bpfloader v0.2+
  T+ must support 4.14+ kernels and T beta3 era bpfloader v0.13+

The kernel affects the intelligence of the in-kernel bpf verifier
and the available bpf helper functions.  Older kernels have
a tendency to reject programs that newer kernels allow.

/ && /vendor are not shipped via mainline, so only need to work
with the bpfloader that's part of the core os.

Bug: 218408035
Test: TreeHugger, manually on cuttlefish
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I674866ebe32aca4fc851818c1ffcbec12ac4f7d4
(cherry picked from commit 15715aea32)
2022-06-22 16:07:42 -07:00

46 lines
1.8 KiB
Text

typeattribute netd coredomain;
typeattribute netd bpfdomain;
init_daemon_domain(netd)
# Allow netd to spawn dnsmasq in it's own domain
domain_auto_trans(netd, dnsmasq_exec, dnsmasq)
allow netd { fs_bpf fs_bpf_netd_readonly fs_bpf_netd_shared }:dir search;
allow netd { fs_bpf fs_bpf_netd_readonly fs_bpf_netd_shared }:file read;
allow netd { fs_bpf fs_bpf_netd_shared }:file write;
# give netd permission to setup iptables rule with xt_bpf, attach program to cgroup, and read/write
# the map created by bpfloader
allow netd bpfloader:bpf { prog_run map_read map_write };
# in order to invoke side effect of close() on such a socket calling synchronize_rcu()
# TODO: Remove this permission when 4.9 kernel is deprecated.
# TODO: Remove this after we remove all bpf interactions from netd.
allow netd self:key_socket create;
set_prop(netd, ctl_mdnsd_prop)
set_prop(netd, netd_stable_secret_prop)
get_prop(netd, adbd_config_prop)
get_prop(netd, bpf_progs_loaded_prop)
get_prop(netd, hwservicemanager_prop)
get_prop(netd, device_config_netd_native_prop)
# Allow netd to write to statsd.
unix_socket_send(netd, statsdw, statsd)
# Allow netd to send callbacks to network_stack
binder_call(netd, network_stack)
# Allow netd to send dump info to dumpstate
allow netd dumpstate:fd use;
allow netd dumpstate:fifo_file { getattr write };
# persist.netd.stable_secret contains RFC 7217 secret key which should never be
# leaked to other processes. Make sure it never leaks.
neverallow { domain -netd -init -dumpstate } netd_stable_secret_prop:file r_file_perms;
# We want to ensure that no other process ever tries tampering with persist.netd.stable_secret,
# the RFC 7217 secret key managed by netd. Doing so could compromise user privacy.
neverallow { domain -netd -init } netd_stable_secret_prop:property_service set;