platform_system_sepolicy/private/netutils_wrapper.te

48 lines
1.9 KiB
Text
Raw Normal View History

typeattribute netutils_wrapper coredomain;
typeattribute netutils_wrapper bpfdomain;
r_dir_file(netutils_wrapper, system_file);
# For netutils (ip, iptables, tc)
allow netutils_wrapper self:global_capability_class_set net_raw;
allow netutils_wrapper system_file:file { execute execute_no_trans };
Start the process of locking down proc/net Files in /proc/net leak information. This change is the first step in determining which files apps may use, whitelisting benign access, and otherwise removing access while providing safe alternative APIs. To that end, this change: * Introduces the proc_net_type attribute which will assigned to any new SELinux types in /proc/net to avoid removing access to privileged processes. These processes may be evaluated later, but are lower priority than apps. * Labels /proc/net/{tcp,tcp6,udp,udp6} as proc_net_vpn due to existing use by VPN apps. This may be replaced by an alternative API. * Audits all other proc/net access for apps. * Audits proc/net access for other processes which are currently granted broad read access to /proc/net but should not be including storaged, zygote, clatd, logd, preopt2cachename and vold. Bug: 9496886 Bug: 68016944 Test: Boot Taimen-userdebug. On both wifi and cellular: stream youtube navigate maps, send text message, make voice call, make video call. Verify no avc "granted" messages in the logs. Test: A few VPN apps including "VPN Monster", "Turbo VPN", and "Freighter". Verify no logspam with the current setup. Test: atest CtsNativeNetTestCases Test: atest netd_integration_test Test: atest QtaguidPermissionTest Test: atest FileSystemPermissionTest Change-Id: I7e49f796a25cf68bc698c6c9206e24af3ae11457 Merged-In: I7e49f796a25cf68bc698c6c9206e24af3ae11457 (cherry picked from commit 087318957f26e921d62f2e234fc14bff3c59030e)
2018-04-10 21:47:48 +02:00
allow netutils_wrapper proc_net_type:file { open read getattr };
allow netutils_wrapper self:rawip_socket create_socket_perms;
allow netutils_wrapper self:udp_socket create_socket_perms;
allow netutils_wrapper self:global_capability_class_set net_admin;
# ip utils need everything but ioctl
allow netutils_wrapper self:netlink_route_socket ~ioctl;
allow netutils_wrapper self:netlink_xfrm_socket ~ioctl;
# For netutils (ndc) to be able to talk to netd
allow netutils_wrapper netd_service:service_manager find;
allow netutils_wrapper dnsresolver_service:service_manager find;
allow netutils_wrapper mdns_service:service_manager find;
binder_use(netutils_wrapper);
binder_call(netutils_wrapper, netd);
# For vendor code that update the iptables rules at runtime. They need to reload
# the whole chain including the xt_bpf rules. They need to access to the pinned
# program when reloading the rule.
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 netutils_wrapper { fs_bpf fs_bpf_netd_shared }:dir search;
allow netutils_wrapper { fs_bpf 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 netutils_wrapper { fs_bpf }:file write;
allow netutils_wrapper bpfloader:bpf prog_run;
# For /data/misc/net access to ndc and ip
r_dir_file(netutils_wrapper, net_data_file)
domain_auto_trans({
domain
-coredomain
-appdomain
}, netutils_wrapper_exec, netutils_wrapper)
# suppress spurious denials
dontaudit netutils_wrapper self:global_capability_class_set sys_resource;
dontaudit netutils_wrapper sysfs_type:file read;
# netutils wrapper may only use the following capabilities.
neverallow netutils_wrapper self:global_capability_class_set ~{ net_admin net_raw };