2018-09-27 19:21:37 +02:00
|
|
|
type bpfloader_exec, system_file_type, exec_type, file_type;
|
2018-01-03 00:31:18 +01:00
|
|
|
|
2022-02-10 01:32:44 +01:00
|
|
|
typeattribute bpfloader bpfdomain;
|
|
|
|
|
|
2022-02-08 00:15:00 +01:00
|
|
|
# allow bpfloader to write to the kernel log (starts early)
|
|
|
|
|
allow bpfloader kmsg_device:chr_file w_file_perms;
|
|
|
|
|
|
2020-01-31 07:08:43 +01:00
|
|
|
# These permissions are required to pin ebpf maps & programs.
|
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 bpfloader bpffs_type:dir { add_name create remove_name search write };
|
2022-07-02 03:20:01 +02:00
|
|
|
allow bpfloader bpffs_type:file { create getattr read rename setattr };
|
2022-07-18 12:34:30 +02:00
|
|
|
allow bpfloader bpffs_type:lnk_file { create 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 { bpffs_type -fs_bpf } fs_bpf:filesystem associate;
|
2018-01-03 00:31:18 +01:00
|
|
|
|
2020-01-31 07:08:43 +01:00
|
|
|
# Allow bpfloader to create bpf maps and programs.
|
|
|
|
|
allow bpfloader self:bpf { map_create map_read map_write prog_load prog_run };
|
2018-01-03 00:31:18 +01:00
|
|
|
|
2021-03-02 08:16:46 +01:00
|
|
|
allow bpfloader self:capability { chown sys_admin net_admin };
|
2018-09-13 20:07:14 +02:00
|
|
|
|
2021-11-12 01:53:26 +01:00
|
|
|
allow bpfloader sysfs_fs_fuse_bpf:file r_file_perms;
|
|
|
|
|
|
2021-01-29 23:36:32 +01:00
|
|
|
set_prop(bpfloader, bpf_progs_loaded_prop)
|
|
|
|
|
|
2022-01-19 07:57:41 +01:00
|
|
|
allow bpfloader bpfloader_exec:file execute_no_trans;
|
|
|
|
|
|
2018-09-13 20:07:14 +02:00
|
|
|
###
|
|
|
|
|
### Neverallow rules
|
|
|
|
|
###
|
2020-01-31 07:08:43 +01:00
|
|
|
|
2021-01-29 23:36:32 +01:00
|
|
|
# TODO: get rid of init & vendor_init; Note: we don't care about getattr/mounton/search
|
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 { domain -init -vendor_init } bpffs_type:dir { open read setattr };
|
|
|
|
|
neverallow { domain -bpfloader } bpffs_type:dir { add_name create remove_name write };
|
|
|
|
|
neverallow domain bpffs_type:dir ~{ add_name create getattr mounton open read remove_name search setattr write };
|
2020-01-31 07:08:43 +01:00
|
|
|
|
|
|
|
|
# TODO: get rid of init & vendor_init
|
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 { domain -bpfloader -init -vendor_init } bpffs_type:file { map open setattr };
|
2022-07-02 03:20:01 +02:00
|
|
|
neverallow { domain -bpfloader } bpffs_type:file { create getattr rename };
|
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 { domain -bpfloader -gpuservice -init -lmkd -mediaprovider_app -netd -netutils_wrapper -system_server -vendor_init } fs_bpf:file read;
|
|
|
|
|
neverallow { domain -bpfloader -init -network_stack -vendor_init } fs_bpf_net_private:file read;
|
|
|
|
|
neverallow { domain -bpfloader -init -network_stack -system_server -vendor_init } fs_bpf_net_shared:file read;
|
|
|
|
|
neverallow { domain -bpfloader -init -netd -network_stack -system_server -vendor_init } fs_bpf_netd_readonly:file read;
|
|
|
|
|
neverallow { domain -bpfloader -init -netd -netutils_wrapper -network_stack -system_server -vendor_init } fs_bpf_netd_shared:file read;
|
|
|
|
|
neverallow { domain -bpfloader -init -network_stack -vendor_init } fs_bpf_tethering:file read;
|
|
|
|
|
neverallow { domain -bpfloader -gpuservice -netd -netutils_wrapper -network_stack -system_server } { bpffs_type -fs_bpf_vendor }:file write;
|
2022-07-02 03:20:01 +02:00
|
|
|
neverallow domain bpffs_type:file ~{ create getattr map open read rename setattr write };
|
2020-01-31 07:08:43 +01:00
|
|
|
|
2022-07-18 12:34:30 +02:00
|
|
|
neverallow { domain -bpfloader } bpffs_type:lnk_file ~read;
|
|
|
|
|
neverallow { domain -bpfdomain } bpffs_type:lnk_file read;
|
|
|
|
|
|
2019-04-09 06:34:53 +02:00
|
|
|
neverallow { domain -bpfloader } *:bpf { map_create prog_load };
|
2019-12-14 00:18:32 +01:00
|
|
|
|
2022-03-08 23:56:27 +01:00
|
|
|
neverallow {
|
|
|
|
|
domain
|
|
|
|
|
-bpfloader
|
|
|
|
|
-gpuservice
|
|
|
|
|
-hal_health_server
|
|
|
|
|
-mediaprovider_app
|
|
|
|
|
-netd
|
|
|
|
|
-netutils_wrapper
|
|
|
|
|
-network_stack
|
|
|
|
|
-system_server
|
|
|
|
|
} *:bpf prog_run;
|
2021-11-11 19:42:11 +01:00
|
|
|
neverallow { domain -bpfloader -gpuservice -lmkd -mediaprovider_app -netd -network_stack -system_server } *:bpf { map_read map_write };
|
2018-11-29 22:07:40 +01:00
|
|
|
neverallow { domain -bpfloader -init } bpfloader_exec:file { execute execute_no_trans };
|
2020-01-31 07:08:43 +01:00
|
|
|
|
2019-12-14 00:18:32 +01:00
|
|
|
neverallow { coredomain -bpfloader -init } fs_bpf_vendor:file *;
|
|
|
|
|
|
2021-01-29 23:36:32 +01:00
|
|
|
neverallow bpfloader *:{ tcp_socket udp_socket rawip_socket } *;
|
2018-05-23 17:36:40 +02:00
|
|
|
|
2018-09-13 20:07:14 +02:00
|
|
|
# No domain should be allowed to ptrace bpfloader
|
|
|
|
|
neverallow { domain userdebug_or_eng(`-llkd') } bpfloader:process ptrace;
|
2021-11-11 10:51:15 +01:00
|
|
|
|
|
|
|
|
# Currently only bpfloader.rc (which runs as init) can do bpf sysctl setup
|
|
|
|
|
# this should perhaps be moved to the bpfloader binary itself. Allow both.
|
|
|
|
|
neverallow { domain -bpfloader -init } proc_bpf:file write;
|
