-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BPF token #5244
BPF token #5244
Conversation
Upstream branch: 3d5786e Pull request is NOT updated. Failed to apply https://patchwork.kernel.org/project/netdevbpf/list/?series=759310
conflict:
|
Upstream branch: 3d5786e |
c8f1cf1
to
0e49b9b
Compare
0d1a06b
to
a4381e8
Compare
Upstream branch: ee77f3d |
0e49b9b
to
a73d07a
Compare
a4381e8
to
a9dfe19
Compare
Upstream branch: 2404dd0 |
a73d07a
to
efa8460
Compare
a9dfe19
to
58f98c2
Compare
Add new kind of BPF kernel object, BPF token. BPF token is meant to to allow delegating privileged BPF functionality, like loading a BPF program or creating a BPF map, from privileged process to a *trusted* unprivileged process, all while have a good amount of control over which privileged operations could be performed using provided BPF token. This patch adds new BPF_TOKEN_CREATE command to bpf() syscall, which allows to create a new BPF token object along with a set of allowed commands that such BPF token allows to unprivileged applications. Currently only BPF_TOKEN_CREATE command itself can be delegated, but other patches gradually add ability to delegate BPF_MAP_CREATE, BPF_BTF_LOAD, and BPF_PROG_LOAD commands. The above means that new BPF tokens can be created using existing BPF token, if original privileged creator allowed BPF_TOKEN_CREATE command. New derived BPF token cannot be more powerful than the original BPF token. Importantly, BPF token is automatically pinned at the specified location inside an instance of BPF FS and cannot be repinned using BPF_OBJ_PIN command, unlike BPF prog/map/btf/link. This provides more control over unintended sharing of BPF tokens through pinning it in another BPF FS instances. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Add low-level wrapper API for BPF_TOKEN_CREATE command in bpf() syscall. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Add a subtest validating BPF_TOKEN_CREATE command, pinning/getting BPF token in/from BPF FS, and creating derived BPF tokens using token_fd parameter. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Allow providing token_fd for BPF_MAP_CREATE command to allow controlled BPF map creation from unprivileged process through delegated BPF token. Further, add a filter of allowed BPF map types to BPF token, specified at BPF token creation time. This, in combination with allowed_cmds allows to create a narrowly-focused BPF token (controlled by privileged agent) with a restrictive set of BPF maps that application can attempt to create. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Add ability to provide token_fd for BPF_MAP_CREATE command through bpf_map_create() API. Also wire through token_create.allowed_map_types param for BPF_TOKEN_CREATE command. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Add test for creating BPF token with support for BPF_MAP_CREATE delegation. And validate that its allowed_map_types filter works as expected and allows to create privileged BPF maps through delegated token, as long as they are allowed by privileged creator of a token. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Accept BPF token FD in BPF_BTF_LOAD command to allow BTF data loading through delegated BPF token. BTF loading is a pretty straightforward operation, so as long as BPF token is created with allow_cmds granting BPF_BTF_LOAD command, kernel proceeds to parsing BTF data and creating BTF object. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Allow user to specify token_fd for bpf_btf_load() API that wraps kernel's BPF_BTF_LOAD command. This allows loading BTF from unprivileged process as long as it has BPF token allowing BPF_BTF_LOAD command, which can be created and delegated by privileged process. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Add a simple test validating that BTF loading can be done from unprivileged process through delegated BPF token. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Add basic support of BPF token to BPF_PROG_LOAD. Extend BPF token to allow specifying BPF_PROG_LOAD as an allowed command, and also allow to specify bit sets of program type and attach type combination that would be allowed to be loaded by requested BPF token. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Instead of performing unconditional system-wide bpf_capable() and perfmon_capable() calls inside bpf_base_func_proto() function (and other similar ones) to determine eligibility of a given BPF helper for a given program, use previously recorded BPF token during BPF_PROG_LOAD command handling to inform the decision. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Remove remaining direct queries to perfmon_capable() and bpf_capable() in BPF verifier logic and instead use BPF token (if available) to make decisions about privileges. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Upstream branch: fbc5669 |
Wire through token_fd into bpf_prog_load(). Also make sure to pass allowed_{prog,attach}_types to kernel in bpf_token_create(). Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Add a test validating that BPF token can be used to load privileged BPF program using privileged BPF helpers through delegated BPF token created by privileged process. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
efa8460
to
c6f7f1f
Compare
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=759310 expired. Closing PR. |
Pull request for series with
subject: BPF token
version: 3
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=759310