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
LMKD needs to be able to attach BPF tracepoints. It needs to be able to
access tracefs, attach and run bpf programs.
Test: m
Test: Verified no denials with lmkd and libmemevents integration
Bug: 244232958
Change-Id: I57248b729c0f011937bec139930ca9d24ba91c3b
Signed-off-by: Carlos Galo <carlosgalo@google.com>
we have CAP_CHOWN but we can't use it
to custom configure directory uid/gid.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I41bdab8d5b7b4cfc5cdc568909c9c6b9947e2bca
(so we can check if we need to change it)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I229a772ec6ecebcd8826730af568980f578842ee
There's no way to currently define a new domain with map_read/write
access.
That's clearly desirable for example for vendor use of xt_bpf programs.
I believe that also holds true for prog_load which is checked
at attachment, and will be needed in the future to support things
like vendor tracepoint attachment.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I6125f3de2f8a8dde0891ddabedfafe35f521e681
This is needed to allow vendor xt_bpf programs.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7ff8a0319bec2f3a57c7ce48939b13b2fca182de
There will not be separate private/public BPF directories. All BPFs will
be under a uprobestats/ directory.
Bug: 296108553
Test: m selinux_policy
Change-Id: I00934cb14ead44c457ccee6957763dc01370dac6
This reverts commit e2bd44d48d.
Reason for revert: 2nd attempt to add the policy change
Test: m selinux_policy
Change-Id: I5b9a102879a65917d496ba2194187ddd2b4545d1
This is so that we can potentially verify that things
are setup right.
Test: TreeHugger
Bug: 275209284
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I59a49cbece2710345fff0b2fb98e32f4e5f3af44
As a reminder, per:
https://source.corp.google.com/search?q=p:aosp-master%20file:sepolicy%20-file:prebuilts%20proc_bpf%20file:genfs
we currently have:
aosp-master system/sepolicy/private/genfs_contexts
genfscon proc /sys/kernel/bpf_ u:object_r:proc_bpf:s0
genfscon proc /sys/kernel/unprivileged_bpf_ u:object_r:proc_bpf:s0
genfscon proc /sys/net/core/bpf_ u:object_r:proc_bpf:s0
So the above are the files which will no longer be writable by init.
A cs/ search for p:android$ (/sys/kernel/bpf_|/sys/kernel/unprivileged_bpf_|/sys/net/core/bpf_) file:[.]rc
only finds bpfloader.rc init script as actually doing these writes.
Those writes are removed in:
https://android-review.git.corp.google.com/c/platform/system/bpf/+/2325617
'bpfloader - move sysctl setting from rc to binary'
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I19ccdf293966dd982e1d36836b0b962d99ed7275
To be used for things that only the bpfloader should be access.
Expected use case is for programs that the bpfloader should load,
pin into the filesystem, *and* attach.
[ie. no need for anything else to attach the programs]
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I035d3fcbf6cee523e41cdde23b8edc13311a45e8
There should be no need for this and it fixes a long outstanding TODO.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id1764cbc713addbbda6827fe6c6689e45e8f584c
(this is to allow /sys/fs/bpf/tethering -> net_shared/tethering
for InProcessTethering, ie. Android Go devices)
Bug: 190523685
Bug: 236925089
Test: TreeHugger, manually on aosp_cf_x86_go_phone-userdebug
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ifa52429f958b0af80f91af6bfb064c1cdf9cd070
(to be able to stat() nodes in /sys/fs/bpf)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ic71ebea683844a8d5ac0b542da815bae2816973a
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 15715aea32)
Require all domains which can be used for BPF to be marked as
bpfdomain, and add a restriction for these domains to not
be able to use net_raw or net_admin. We want to make sure the
network stack has exclusive access to certain BPF attach
points.
Bug: 140330870
Bug: 162057235
Test: build (compile-time neverallows)
Change-Id: I29100e48a757fdcf600931d5eb42988101275325
Who needs all those context switches?
bpfloader controls which types of vendor programs can be used.
Bug: 140330870
Bug: 162057235
Test: successfully load bpf programs from vendor
Change-Id: I36e4f6550da33fea5bad509470dfd39f301f13c8
btfloader is a standalone binary that receives a path to a bpf .o file
from bpfloader, parses & loads the BTF type info from the file, passes
BTF info back to bpfloader & exits. Include it in bpfloader's domain &
grant bpfloader permission to run it.
Bug: 203823368
Test: build & boot, bpfloader successfully executes btfloader
Signed-off-by: Connor O'Brien <connoro@google.com>
Change-Id: Ia08776a90763a8477d9f3e393d5d723b88a3176f
The FUSE daemon in MediaProvider needs to access the file descriptor of
its pinned BPF program and the maps used to commuicate with the kernel.
Bug: 202785178
Test: adb logcat FuseDaemon:V \*:S (in git_master)
Ignore-AOSP-First: mirroring AOSP for prototyping
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: I99d641658d37fb765ecc5d5c0113962f134ee1ae
Bug: 202785178
Test: Along with rest of topic, file
/sys/fs/bpf/prog_fuse_media_fuse_media
appears on boot with fuse-bpf in kernel
Merged-In: Ibccdf177c75fef0314c86319be3f0b0f249ce59d
Change-Id: Ibccdf177c75fef0314c86319be3f0b0f249ce59d
This is required for it to be able to create DEVMAP/DEVMAP_HASH maps.
See kernel source code in kernel/bpf/devmap.c:
static struct bpf_map *dev_map_alloc(union bpf_attr *attr) {
...
if (!capable(CAP_NET_ADMIN)) return ERR_PTR(-EPERM);
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2fc5b1541133859857fc9baa7564965f240c842a
We want to label /sys/fs/bpf/tethering/... with a new label distinct
from /sys/fs/bpf, as this will allow locking down the programs/maps
tighter then is currently possible with the existing system.
These programs and maps are provided via the tethering mainline module,
and as such their number, names, key/value types, etc. are all prone to
be changed by a tethering mainline module update.
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ifc4108d76a1106a936b941a3dda1abc5a65c05b0
(and while we're at it make sure noone else creates subdirs)
Resolves:
avc: denied { create } for comm="bpfloader" name="tethering" scontext=u:r:bpfloader:s0 tcontext=u:object_r:fs_bpf:s0 tclass=dir
Test: builds and boots with bpfloader changes
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I27a4e0793ed039feab84ac5658e36b68dcca2631
1. Allow gpuservice to access tracepoint id
2. Allow gpuservice to access bpf program
3. Allow gpuservice to attach bpf program to tracepoint
4. Allow gpuservice to access bpf filesystem
5. Allow gpuservice to run bpf program and read map through bpfloader
6. Allow gpuservice to check a property to ensure bpf program loaded
Bug: 136023082
Test: adb shell dumpsys gpu --gpumem
Change-Id: Ic808a7e452b71c54908cdff806f41f51ab66ffd8
This is driven by 3 things:
- netd no longer needs setattr, since this is now done by bpfloader
- nothing should ever unpin maps or programs
- generic cleanups and additional neverallows
Test: build, atest
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I881cc8bf9fe062aaff709727406c5a51fc363c8e
so that it can change the uid/gid of pinned bpf progs and maps
Test: build, atest
Bug: 149434314
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1d873c7799e1d9fa5d4bde145e89254dabb75a01
In order to track time in state data using eBPF, system_server needs
to be able to attach BPF programs to tracepoints, which involves:
- calling perf_event_open and the PERF_EVENT_IOC_SET_BPF ioctl
- running BPF programs
- reading tracepoint ids from tracefs
Grant system_server the necessary permissions for these tasks
Test: modify system_server to try to attach programs; check for
denials
Bug: 138317993
Change-Id: I07dafd325a9c57d53767a09d4ca7b0fb2dd2d328
Signed-off-by: Connor O'Brien <connoro@google.com>
bpf programs/maps are now loaded by the bpfloader, not netd
Test: built/installed on crosshatch which uses eBPF - no avc denials
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1ebd82e6730d62d1966da3c4634ecd78ce703543
init needs to execute bpfloader as a one-shot service. Add sepolicy for
the same. Also update old rules allowing init to fork/exec bpfloader and
remove rules allowing netd to do so.
Bug: 112334572
Change-Id: Ic242cd507731ed8af3f8e94d4fccc95819831d37
Signed-off-by: Joel Fernandes <joelaf@google.com>
bpfloader needs to load bpf programs with tracepoints in them. The
tracepoint programs are not activated but are just loaded and pinned.
The kernel expects the process doing this to have CAP_SYS_ADMIN. Since
bpfloader was intended to be a 1-shot run and exit process with security
privileges, lets assign it CAP_SYS_ADMIN so that it is able to load the
tracepoint programs.
Bug: 112334572
Change-Id: Icf9b5d95615e69f5c28dc28f021b07f49710c97d
Signed-off-by: Joel Fernandes <joelaf@google.com>
Recent change in netd and bpfloader switched the creater of bpf maps
from netd to bpfloader. Change the rules related to it to make sure it
doesn't fail.
Test: dumpsys netd trafficcontroller
Bug: 112334572
Change-Id: I016ff68b58ef7b12bdfdebc2fd178be1d0206a62
system_file_type is a new attribute used to identify files which exist
on the /system partition. It's useful for allow rules in init, which are
based off of a blacklist of writable files. Additionally, it's useful
for constructing neverallow rules to prevent regressions.
Additionally, add commented out tests which enforce that all files on
the /system partition have the system_file_type attribute. These tests
will be uncommented in a future change after all the device-specific
policies are cleaned up.
Test: Device boots and no obvious problems.
Change-Id: Id9bae6625f042594c8eba74ca712abb09702c1e5
Add additional compile time constraints on the ability to ptrace various
sensitive domains.
llkd: remove some domains which llkd should never ptrace, even on
debuggable builds, such as kernel threads and init.
crash_dump neverallows: Remove the ptrace neverallow checks because
it duplicates other neverallow assertions spread throughout the policy.
Test: policy compiles and device boots
Change-Id: Ia4240d1ce7143b983bb048e046bb4729d0af5a6e
commit 9b2e0cbeea added a new
self:global_capability_class_set macro that covers both self:capability
and self:cap_userns. Apply the new macro to various self:capability
references that have cropped up since then.
Bug: 112307595
Test: policy diff shows new rules are all cap_userns
Change-Id: I3eb38ef07532a8e693fd549dfdbc4a6df5329609
The netutils_wrapper is a process used by vendor code to update the
iptable rules on devices. When it update the rules for a specific chain.
The iptable module will reload the whole chain with the new rule. So
even the netutils_wrapper do not need to add any rules related to xt_bpf
module, it will still reloading the existing iptables rules about xt_bpf
module and need pass through the selinux check again when the rules are
reloading. So we have to grant it the permission to reuse the pinned
program in fs_bpf when it modifies the corresponding iptables chain so
the vendor module will not crash anymore.
Test: device boot and no more denials from netutils_wrapper
Bug: 72111305
Change-Id: I62bdfd922c8194c61b13e2855839aee3f1e349be
(cherry picked from aosp commit 2623ebcf8e)
To better record the network traffic stats for each network interface.
We use xt_bpf netfilter module to do the iface stats accounting instead
of the cgroup bpf filter we currently use for per uid stats accounting.
The xt_bpf module will take pinned eBPF program as iptables rule and run
the program when packet pass through the netfilter hook. To setup the
iptables rules. netd need to be able to access bpf filesystem and run the
bpf program at boot time. The program used will still be created and
pinned by the bpfloader process.
Test: With selinux enforced, run "iptables -L -t raw" should show the
xt_bpf related rule present in bw_raw_PREROUTING chain.
Bug: 72111305
Change-Id: I11efe158d6bd5499df6adf15e8123a76cd67de04
(cherry picked from aosp commit 5c95c16841)
With the new patches backported to 4.9 kernels, the bpf file system now
take the same file open flag as bpf_obj_get. So system server now need
read permission only for both bpf map and fs_bpf since we do not need
system server to edit the map. Also, the netd will always pass stdin
stdout fd to the process forked by it and do allow it will cause the
fork and execev fail. We just allow it pass the fd to bpfloader for now
until we have a better option.
Test: bpfloader start successful on devices with 4.9 kernel.
run cts -m CtsNetTestCases -t android.net.cts.TrafficStatsTest
Bug: 74096311
Bug: 30950746
Change-Id: I747a51cb05ae495c155e7625a3021fc77f921e0d
Add a new set of sepolicy for the process that only netd use to load
and run ebpf programs. It is the only process that can load eBPF
programs into the kernel and is only used to do that. Add some
neverallow rules regarding which processes have access to bpf objects.
Test: program successfully loaded and pinned at sys/fs/bpf after device
boot. No selinux violation for bpfloader
Bug: 30950746
Change-Id: Ia6bb1afda29ae0749bdc368e2dfc5faa12e81b2f
