On Thu, Apr 16, 2020 at 6:58 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > On Wed, Apr 15, 2020 at 9:22 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > From: Paul Moore <paul@xxxxxxxxxxxxxx> > > > > Historically the Fedora Kernels have been built with the > > kernel.unprivileged_bpf_disabled set to 0, which skipped a > > CAP_SYS_ADMIN check in the bpf() syscall. However, starting > > with the Fedora Rawhide v5.7-rcX kernel builds this sysctl > > is now set to 1 which is triggering a CAP_SYS_ADMIN check > > when performing bpf() operations. > > > > Add the capability:sys_admin to the BPF test domains so they can > > pass this newly triggered check. > > > > Signed-off-by: Paul Moore <paul@xxxxxxxxxxxxxx> > > --- > > policy/test_binder_bpf.te | 2 +- > > policy/test_bpf.te | 12 ++++++------ > > policy/test_fdreceive_bpf.te | 6 +++--- > > 3 files changed, 10 insertions(+), 10 deletions(-) > > I have been applying a similar workaround in our RHEL testing, because > I encountered the same setting on RHEL-8. Interesting that Fedora is > doing the same thing now... Perhaps this is an unintended consequence > of the recent workflow change? I suspect it is due to CVE-2020-8835 and not the Fedora kernel workflow change. Although the workflow change was annoying enough in its own way, unrelated to this issue. I had to add a bunch of hacks to my kernel-secnext automation to get things working again (one of the reasons the post-rc1 patch merging was delayed a day or two). > Anyway, it seems better to have the > test ready to work regardless of the sysctl value, so: > > Acked-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx> -- paul moore www.paul-moore.com
