2019-11-22 18:33:37 +01:00
|
|
|
# Networking service app
|
2022-02-10 01:32:44 +01:00
|
|
|
typeattribute network_stack coredomain;
|
|
|
|
|
typeattribute network_stack mlstrustedsubject;
|
|
|
|
|
typeattribute network_stack bpfdomain;
|
2018-11-14 09:07:41 +01:00
|
|
|
|
|
|
|
|
app_domain(network_stack);
|
|
|
|
|
net_domain(network_stack);
|
|
|
|
|
|
|
|
|
|
allow network_stack self:global_capability_class_set {
|
|
|
|
|
net_admin
|
|
|
|
|
net_bind_service
|
|
|
|
|
net_broadcast
|
|
|
|
|
net_raw
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
# Allow access to net_admin ioctl, DHCP server uses SIOCSARP
|
|
|
|
|
allowxperm network_stack self:udp_socket ioctl priv_sock_ioctls;
|
|
|
|
|
|
|
|
|
|
# The DhcpClient uses packet_sockets
|
|
|
|
|
allow network_stack self:packet_socket create_socket_perms_no_ioctl;
|
|
|
|
|
|
2019-01-28 05:08:42 +01:00
|
|
|
# Monitor neighbors via netlink.
|
|
|
|
|
allow network_stack self:netlink_route_socket nlmsg_write;
|
|
|
|
|
|
2022-05-20 06:34:31 +02:00
|
|
|
# Use netlink uevent sockets.
|
|
|
|
|
allow network_stack self:netlink_kobject_uevent_socket create_socket_perms_no_ioctl;
|
|
|
|
|
|
|
|
|
|
# give network_stack the same netlink permissions as netd
|
|
|
|
|
allow network_stack self:netlink_nflog_socket create_socket_perms_no_ioctl;
|
|
|
|
|
allow network_stack self:netlink_socket create_socket_perms_no_ioctl;
|
|
|
|
|
allow network_stack self:netlink_generic_socket create_socket_perms_no_ioctl;
|
|
|
|
|
|
2019-01-10 23:35:17 +01:00
|
|
|
allow network_stack app_api_service:service_manager find;
|
2019-02-25 13:12:15 +01:00
|
|
|
allow network_stack dnsresolver_service:service_manager find;
|
2021-12-09 04:49:23 +01:00
|
|
|
allow network_stack mdns_service:service_manager find;
|
2018-11-14 09:07:41 +01:00
|
|
|
allow network_stack netd_service:service_manager find;
|
2021-04-14 12:24:50 +02:00
|
|
|
allow network_stack network_watchlist_service:service_manager find;
|
2019-01-15 08:57:32 +01:00
|
|
|
allow network_stack radio_service:service_manager find;
|
2021-04-14 12:24:50 +02:00
|
|
|
allow network_stack system_config_service:service_manager find;
|
2019-03-08 04:33:03 +01:00
|
|
|
allow network_stack radio_data_file:dir create_dir_perms;
|
|
|
|
|
allow network_stack radio_data_file:file create_file_perms;
|
2018-11-14 09:07:41 +01:00
|
|
|
|
|
|
|
|
binder_call(network_stack, netd);
|
2019-10-01 22:49:21 +02:00
|
|
|
|
2021-01-29 23:36:32 +01:00
|
|
|
# in order to invoke side effect of close() on such a socket calling synchronize_rcu()
|
|
|
|
|
allow network_stack self:key_socket create;
|
2021-04-09 16:29:29 +02:00
|
|
|
# Java's Os.close() in libcore/luni/src/main/java/libcore/io/BlockGuardOs.java;l=100
|
|
|
|
|
# calls if (fd.isSocket$()) if (isLingerSocket(fd)) ...
|
|
|
|
|
dontaudit network_stack self:key_socket getopt;
|
2021-01-29 23:36:32 +01:00
|
|
|
|
|
|
|
|
# Grant read permission of connectivity namespace system property prefix.
|
|
|
|
|
get_prop(network_stack, device_config_connectivity_prop)
|
|
|
|
|
|
2019-10-12 13:49:23 +02:00
|
|
|
# Create/use netlink_tcpdiag_socket to get tcp info
|
|
|
|
|
allow network_stack self:netlink_tcpdiag_socket { create_socket_perms_no_ioctl nlmsg_read nlmsg_write };
|
2019-11-21 05:58:31 +01:00
|
|
|
############### Tethering Service app - Tethering.apk ##############
|
|
|
|
|
hal_client_domain(network_stack, hal_tetheroffload)
|
|
|
|
|
# Create and share netlink_netfilter_sockets for tetheroffload.
|
|
|
|
|
allow network_stack self:netlink_netfilter_socket create_socket_perms_no_ioctl;
|
2019-12-12 05:54:57 +01:00
|
|
|
allow network_stack network_stack_service:service_manager find;
|
2020-11-26 02:55:56 +01:00
|
|
|
# allow Tethering(network_stack process) to run/update/read the eBPF maps to offload tethering traffic by eBPF.
|
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 network_stack { fs_bpf_net_private fs_bpf_net_shared fs_bpf_netd_readonly fs_bpf_netd_shared fs_bpf_tethering }:dir search;
|
2023-03-28 03:14:40 +02:00
|
|
|
allow network_stack { fs_bpf_net_private fs_bpf_net_shared fs_bpf_netd_readonly fs_bpf_netd_shared fs_bpf_tethering }:file { getattr read write };
|
2020-11-26 02:55:56 +01:00
|
|
|
allow network_stack bpfloader:bpf { map_read map_write prog_run };
|
2023-05-11 12:36:18 +02:00
|
|
|
# allow Tethering(network_stack process) to read flag value in tethering_u_or_later_native namespace
|
|
|
|
|
get_prop(network_stack, device_config_tethering_u_or_later_native_prop)
|
2020-12-03 05:45:36 +01:00
|
|
|
|
2022-05-20 22:55:32 +02:00
|
|
|
# Use XFRM (IPsec) netlink sockets
|
|
|
|
|
allow network_stack self:netlink_xfrm_socket { create_socket_perms_no_ioctl nlmsg_write nlmsg_read };
|
|
|
|
|
|
2022-06-01 05:29:55 +02:00
|
|
|
# tun device used for 3rd party vpn apps and test network manager
|
|
|
|
|
allow network_stack tun_device:chr_file rw_file_perms;
|
|
|
|
|
allowxperm network_stack tun_device:chr_file ioctl { TUNGETIFF TUNSETIFF TUNSETLINK TUNSETCARRIER };
|
|
|
|
|
|
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
|
|
|
############### NEVER ALLOW RULES
|
|
|
|
|
# This place is as good as any for these rules,
|
|
|
|
|
# and it is probably the most appropriate because
|
|
|
|
|
# network_stack itself is entirely mainline code.
|
|
|
|
|
|
|
|
|
|
# T+: Only the bpfloader and the network_stack should ever touch 'fs_bpf_net_private' programs/maps.
|
2022-12-01 15:45:35 +01:00
|
|
|
neverallow { domain -bpfloader -network_stack } fs_bpf_net_private:dir ~getattr;
|
|
|
|
|
neverallow { domain -bpfloader -network_stack } fs_bpf_net_private:file *;
|
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
|
|
|
|
|
|
|
|
# T+: Only the bpfloader, network_stack and system_server should ever touch 'fs_bpf_net_shared' programs/maps.
|
2022-12-01 15:45:35 +01:00
|
|
|
neverallow { domain -bpfloader -network_stack -system_server } fs_bpf_net_shared:dir ~getattr;
|
|
|
|
|
neverallow { domain -bpfloader -network_stack -system_server } fs_bpf_net_shared:file *;
|
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
|
|
|
|
|
|
|
|
# T+: Only the bpfloader, netd, network_stack and system_server should ever touch 'fs_bpf_netd_readonly' programs/maps.
|
|
|
|
|
# netd's access should be readonly
|
2022-12-01 15:45:35 +01:00
|
|
|
neverallow { domain -bpfloader -netd -network_stack -system_server } fs_bpf_netd_readonly:dir ~getattr;
|
|
|
|
|
neverallow { domain -bpfloader -netd -network_stack -system_server } fs_bpf_netd_readonly:file *;
|
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
|
|
|
neverallow netd fs_bpf_netd_readonly:file write;
|
|
|
|
|
|
|
|
|
|
# T+: Only the bpfloader, netd, netutils_wrapper, network_stack and system_server should ever touch 'fs_bpf_netd_shared' programs/maps.
|
|
|
|
|
# netutils_wrapper requires access to be able to run iptables and only needs readonly access
|
2022-12-01 15:45:35 +01:00
|
|
|
neverallow { domain -bpfloader -netd -netutils_wrapper -network_stack -system_server } fs_bpf_netd_shared:dir ~getattr;
|
|
|
|
|
neverallow { domain -bpfloader -netd -netutils_wrapper -network_stack -system_server } fs_bpf_netd_shared:file *;
|
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
|
|
|
neverallow netutils_wrapper fs_bpf_netd_shared:file write;
|
|
|
|
|
|
|
|
|
|
# S+: Only the bpfloader and the network_stack should ever touch 'fs_bpf_tethering' programs/maps.
|
2022-12-01 15:45:35 +01:00
|
|
|
neverallow { domain -bpfloader -network_stack } fs_bpf_tethering:dir ~getattr;
|
|
|
|
|
neverallow { domain -bpfloader -network_stack } fs_bpf_tethering:file *;
|
