allow non bpfloader creation of bpf maps
In practice only bpf programs are critical to device security...
Normally there is basically no use for creating bpf maps outside
of the bpfloader, since they have to be tied directly into the bpf
programs (which is only ever done by the bpfloader during the boot
process) to be of any use.
This means that bpf maps created after the bpfloader is done,
can't actually be used by any bpf code...
Hence we had this restriction.
However, map-in-map support changes this:
It becomes possible to define a boot-time (bpfloader loaded)
bpf program which accesses an (initially empty) outer map
(created by the bpfloader).
This outer map can be populated with inner maps at run time by various
bpf using userspace code. While it can be populated with bpfloader
created 'static' maps, it also makes sense to be able to create/destroy
these inner maps on demand 'dynamically'.
This allows bpf map memory utilization to be driven by actual runtime
device needs. For example scaling with the number of users, apps,
or connected networks.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I93223c660463596c9e50065be819e2fd865da923
diff --git a/private/bpfloader.te b/private/bpfloader.te
index de7e8a4..33d3783 100644
--- a/private/bpfloader.te
+++ b/private/bpfloader.te
@@ -47,8 +47,8 @@
neverallow { domain -bpfloader } bpffs_type:lnk_file ~read;
neverallow { domain -bpfdomain } bpffs_type:lnk_file read;
-neverallow { domain -bpfloader } *:bpf { map_create prog_load };
-neverallow { domain -bpfdomain } *:bpf { map_read map_write prog_run };
+neverallow { domain -bpfloader } *:bpf prog_load;
+neverallow { domain -bpfdomain } *:bpf { map_create map_read map_write prog_run };
# 'fs_bpf_loader' is for internal use of the BpfLoader oneshot boot time process.
neverallow { domain -bpfloader } fs_bpf_loader:bpf *;