1. Please describe the problem: Making the default kernel boot into "confidentiality" lockdown breaks a lot of production-observability functionality that relies on eBPF. This means that performance-monitoring tools like BCC will not work (see bug report here: https://github.com/iovisor/bcc/issues/2565) but also that other security tools that rely on eBPF to perform host introspection / monitoring will no longer work by default. In general, it is unclear to me what the precise threat model is that "confidentiality" lockdown defends against; and why all bpf_probe_read and bpf_probe_read_str is blacklisted etc. Solution to the problem: Do not default-boot into "lockdown" kernels. IF you absolutely must (and there are few reasons why one would do so), the "integrity" mode is less harmful to production use & inspectability. The lockdown patchset and "confidentiality" mode are excessive for 2. What is the Version-Release number of the kernel: The relevant LKML upstream merge is https://lkml.org/lkml/2019/9/10/856 I am not 100% sure when Fedora decided to make "confidentiality" the default. 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : AFAIK Fedora 30 did not ship a kernel in "confidentiality" lockdown; Fedora 31 does. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: See the bug reports under https://github.com/iovisor/bcc/issues/2565 and https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-lifting-the-kernel-lockdown/ 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: It will; this is not a "bug" per se; rather the decision to enable a highly-controversial and very very intrusive kernel feature by default.
I 100% agree with Thomas. Having the default kernel boot into "confidentiality" lockdown will dramatically reduce the security industry's ability to detect real attacks, making this a huge net negative for the industry. I'm happy to show you, for instance, a real exploit chain (against published CVEs) that takes a containerized nginx on an SE-Linux enabled system that: 1) Escapes the container 2) Disables SE Linux 3) Does not drop anything that would violate an SELinux policy 4) Puts SE Linux into permissive mode. 5) Does not get detected as an attack by anything stock, including SELinux. There are plenty of viable detection techniques that can catch such a chain, all of which will be broken if this patch is the default. Please, let's learn from the Microsoft PatchGuard debacle.