-
Notifications
You must be signed in to change notification settings - Fork 96
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 and BPF FS-based delegation #5959
Conversation
Upstream branch: 155addf |
77f4da6
to
8733869
Compare
Upstream branch: 155addf |
6b2ef2e
to
bb0a296
Compare
8733869
to
94d3865
Compare
Upstream branch: 689b097 |
bb0a296
to
c3b5137
Compare
94d3865
to
91eb9b4
Compare
Upstream branch: 9241176 |
c3b5137
to
e31f728
Compare
41cefa5
to
f451eac
Compare
Upstream branch: b8e3a87 |
e31f728
to
c47428f
Compare
f451eac
to
176a371
Compare
Upstream branch: 100888f |
c47428f
to
bbcaf29
Compare
176a371
to
ccfd26f
Compare
Upstream branch: 100888f |
bbcaf29
to
4f5cde1
Compare
ccfd26f
to
84d2b11
Compare
Upstream branch: 727a92d |
4f5cde1
to
1c27fb5
Compare
Wire through token_fd into bpf_prog_load(). Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Add a selftest that attempts to conceptually replicate intended BPF token use cases inside user namespaced container. Child process is forked. It is then put into its own userns and mountns. Child creates BPF FS context object. This ensures child userns is captured as the owning userns for this instance of BPF FS. Given setting delegation mount options is privileged operation, we ensure that child cannot set them. This context is passed back to privileged parent process through Unix socket, where parent sets up delegation options, creates, and mounts it as a detached mount. This mount FD is passed back to the child to be used for BPF token creation, which allows otherwise privileged BPF operations to succeed inside userns. We validate that all of token-enabled privileged commands (BPF_BTF_LOAD, BPF_MAP_CREATE, and BPF_PROG_LOAD) work as intended. They should only succeed inside the userns if a) BPF token is provided with proper allowed sets of commands and types; and b) namespaces CAP_BPF and other privileges are set. Lacking a) or b) should lead to -EPERM failures. Based on suggested workflow by Christian Brauner ([0]). [0] https://lore.kernel.org/bpf/20230704-hochverdient-lehne-eeb9eeef785e@brauner/ Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Utilize newly added bpf_token_create/bpf_token_free LSM hooks to allocate struct bpf_security_struct for each BPF token object in SELinux. This just follows similar pattern for BPF prog and map. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Upstream branch: 81427a6 |
1c27fb5
to
fc83b80
Compare
62ac320
to
802cd95
Compare
Upstream branch: 9cea90c Pull request is NOT updated. Failed to apply https://patchwork.kernel.org/project/netdevbpf/list/?series=800113
conflict:
|
467c88c
to
3f7a266
Compare
1e895db
to
3e705c2
Compare
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=798725 irrelevant now. Closing PR. |
Pull request for series with
subject: BPF token and BPF FS-based delegation
version: 10
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=800113