Re: [RFC PATCH v2] bpf: use bpf_capable() instead of CAP_SYS_ADMIN for blinding decision
From: "Serge E. Hallyn" <serge@hallyn.com>
Date: 2022-08-31 18:50:50
Also in:
bpf
On Wed, Aug 31, 2022 at 06:24:14PM +0300, Yauheni Kaliuta wrote:
The capability check can cause SELinux denial. For example, in ptp4l, setsockopt() with the SO_ATTACH_FILTER option raises sk_attach_filter() to run a bpf program. SELinux hooks into capable() calls and performs an additional check if the task's SELinux domain has permission to "use" the given capability. ptp4l_t already has CAP_BPF granted by SELinux, so if the function used bpf_capable() as most BPF code does, there would be no change needed in selinux-policy.
The selinux mentions probably aren't really necessary. The more concise way to say it is that bpf_jit_blinding_enabled() should be permitted with CAP_BPF, that full CAP_SYS_ADMIN is not needed. (Assuming that that is the case)
quoted hunk ↗ jump to hunk
Signed-off-by: Yauheni Kaliuta <redacted> --- v2: put the reasoning in the commit message --- include/linux/filter.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)diff --git a/include/linux/filter.h b/include/linux/filter.h index a5f21dc3c432..3de96b1a736b 100644 --- a/include/linux/filter.h +++ b/include/linux/filter.h@@ -1100,7 +1100,7 @@ static inline bool bpf_jit_blinding_enabled(struct bpf_prog *prog) return false; if (!bpf_jit_harden) return false; - if (bpf_jit_harden == 1 && capable(CAP_SYS_ADMIN)) + if (bpf_jit_harden == 1 && bpf_capable()) return false; return true;-- 2.34.1