2017-03-23 22:27:32 +01:00
|
|
|
typeattribute netd coredomain;
|
2022-02-10 01:32:44 +01:00
|
|
|
typeattribute netd bpfdomain;
|
2017-03-23 22:27:32 +01:00
|
|
|
|
2016-07-22 22:13:11 +02:00
|
|
|
init_daemon_domain(netd)
|
|
|
|
|
|
|
|
|
|
# Allow netd to spawn dnsmasq in it's own domain
|
|
|
|
|
domain_auto_trans(netd, dnsmasq_exec, dnsmasq)
|
|
|
|
|
|
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 15715aea32b85c933778b97a46de6ccab42ca7fb)
2022-05-21 14:03:29 +02:00
|
|
|
allow netd { fs_bpf fs_bpf_netd_readonly fs_bpf_netd_shared }:dir search;
|
2023-03-28 03:14:40 +02:00
|
|
|
allow netd { fs_bpf fs_bpf_netd_readonly fs_bpf_netd_shared }:file { getattr read };
|
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 15715aea32b85c933778b97a46de6ccab42ca7fb)
2022-05-21 14:03:29 +02:00
|
|
|
allow netd { fs_bpf fs_bpf_netd_shared }:file write;
|
|
|
|
|
|
2018-12-05 02:57:27 +01:00
|
|
|
# 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 };
|
2019-01-11 14:32:45 +01:00
|
|
|
|
2019-02-28 02:44:26 +01:00
|
|
|
# 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.
|
2022-01-28 08:04:09 +01:00
|
|
|
# TODO: Remove this after we remove all bpf interactions from netd.
|
2019-02-28 02:44:26 +01:00
|
|
|
allow netd self:key_socket create;
|
|
|
|
|
|
2020-03-04 09:20:35 +01:00
|
|
|
set_prop(netd, ctl_mdnsd_prop)
|
|
|
|
|
set_prop(netd, netd_stable_secret_prop)
|
|
|
|
|
|
2021-01-26 06:34:00 +01:00
|
|
|
get_prop(netd, adbd_config_prop)
|
2020-03-04 09:20:35 +01:00
|
|
|
get_prop(netd, hwservicemanager_prop)
|
|
|
|
|
get_prop(netd, device_config_netd_native_prop)
|
2018-11-21 15:53:48 +01:00
|
|
|
|
|
|
|
|
# Allow netd to write to statsd.
|
|
|
|
|
unix_socket_send(netd, statsdw, statsd)
|
2019-01-28 05:08:42 +01:00
|
|
|
|
|
|
|
|
# Allow netd to send callbacks to network_stack
|
|
|
|
|
binder_call(netd, network_stack)
|
|
|
|
|
|
2019-04-05 10:33:56 +02:00
|
|
|
# Allow netd to send dump info to dumpstate
|
|
|
|
|
allow netd dumpstate:fd use;
|
|
|
|
|
allow netd dumpstate:fifo_file { getattr write };
|
2020-03-04 09:20:35 +01:00
|
|
|
|
|
|
|
|
# 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;
|
