> From: David Sastre [mailto:d.sastre.medina@xxxxxxxxx] > Sent: Saturday, February 19, 2022 11:56 PM > (Secure Boot is concerned only with verifying the trustworthiness of the > bootloader. > From https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html: > The Kernel Lockdown feature is designed to prevent both direct > and indirect access to a running kernel image, attempting to > protect against unauthorized modification of the kernel image and > to prevent access to security and cryptographic data located in > kernel memory, whilst still permitting driver modules to be > loaded. > eBPF does not require loading additional kernel modules, perhaps you were > thinking of systemtap?, > nor does it need to modify the kernel image.) Thanks David. If I remember correctly, there could be some limitations if the Lockdown LSM is in confidentiality mode. By default in Fedora it is in integrity mode. I tried to run my eBPF in a system with secure boot enabled and it seems to work (there are some issues with how gnome-shell uses mmap(), I will fix them). Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > To verify this works on current stable, you can try: > > # hostnamectl | rg -i cpe > CPE OS Name: cpe:/o:fedoraproject:fedora:35 > > > # bootctl | rg -i secure.*boot > systemd-boot not installed in ESP. > Secure Boot: enabled > > > # cat /sys/kernel/security/lockdown > none [integrity] confidentiality > > > # rpm -q bcc-tools > bcc-tools-0.21.0-1.fc35.x86_64 > > > # rpm -ql bcc-tools | rg bitesize > /usr/share/bcc/tools/bitesize > /usr/share/bcc/tools/doc/bitesize_example.txt > /usr/share/man/man8/bcc-bitesize.8.gz > > > # /usr/share/bcc/tools/bitesize > Tracing block I/O... Hit Ctrl-C to end. > ^C > Process Name = dmcrypt_write/2 > Kbytes : count distribution > 0 -> 1 : 0 | | > 2 -> 3 : 0 | | > 4 -> 7 : 195 |********** | > 8 -> 15 : 42 |** | > 16 -> 31 : 756 |****************************************| > 32 -> 63 : 166 |******** | > 64 -> 127 : 24 |* | > 128 -> 255 : 5 | | > 256 -> 511 : 99 |***** | > ... > > > The bcc-tools package is a collection of eBPF programs > (https://github.com/iovisor/bcc). > > > Alternatively, the much simpler > https://gist.github.com/lizrice/47ad44a15cce912502f8667a403f5649#file- > hello_world-py > > (requires python3-bcc): > > # cat << 'EOF' > hi.py > #!/usr/bin/python > from bcc import BPF > > prog = """ > int hello(void *ctx) { > bpf_trace_printk("Hello world\\n"); > return 0; > } > """ > > b = BPF(text=prog) > clone = b.get_syscall_fnname("clone") > b.attach_kprobe(event=clone, fn_name="hello") > b.trace_print() > > EOF > > > > # strace -e bpf ./hi.py > > > Hope that helps. > > > > On Fri, Feb 18, 2022 at 6:50 PM Fabio Valentini <decathorpe@xxxxxxxxx > <mailto:decathorpe@xxxxxxxxx> > wrote: > > > On Fri, Feb 18, 2022 at 4:27 PM Roberto Sassu via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx <mailto:devel@xxxxxxxxxxxxxxxxxxxxxxx> > > wrote: > > > > Hi everyone > > > > I have very exciting news to share. > > > > Given the difficulty to have the DIGLIM kernel patches > > accepted, I checked if I could achieve the same goals > > with an eBPF program. > > > > I focused only on the functionality side, it is probably > > required some support from the kernel to have the > > same security guarantees of an LSM integrated in the > > kernel. > > > > But, at least for the functionality part, I would say that > > thanks to the very extensive support from eBPF, I managed > > to almost match what I provided with the kernel patches > > (at least for appraisal, not for measurement). > > > > This is the repo with the code: > > > > https://github.com/robertosassu/diglim-ebpf > > > > and the Copr project with binary packages: > > > > https://copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM-eBPF/ > > > > Unfortunately, due to a feature introduced only recently > > (allow sleepable programs to use the inode map), it will > > work only with Fedora 36. Probably, commit 0fe4b381a59e > > ("bpf: Allow bpf_local_storage to be used by sleepable programs) > > applied to the kernel 5.16 would be sufficient to use > > DIGLIM eBPF also in Fedora 35. > > > > Unlike the previous version of DIGLIM, this one does not > > have any dependency (I just had to add rpmplugin.h in > > the rpm-devel package). > > > > It can be configured with two simple commands (please > > do it in a testing VM): > > > > # dnf copr enable robertosassu/DIGLIM-eBPF > > # diglim_setup.sh install --default > > > > After reboot, the kernel will refuse to execute anything > > that is not in a package. Updating a package or installing > > new ones is supported, DIGLIM eBPF takes care of loading > > the new reference values. > > > > Adding custom software is also possible, as shown with the > > following commands: > > > > # ./script.sh > > -bash: ./script.sh: /bin/bash: bad interpreter: Operation not permitted > > # compact_gen -d /etc/digest_lists -i script.sh > > # diglim_user_client -o add -p /etc/digest_lists/0-file_list-compact- > script.sh > > Digest list command successful > > # ./script.sh > > Hello world! > > > > I know it is too late for Fedora 36, but I hope you could > > consider this version for Fedora 37. In the meantime, I will > > work on the security guarantees (signature verification of > > the digest lists, avoid unplugging of the LSM). > > > > Any comment or suggestion is very appreciated! > > > > Thanks > > > > Roberto > > I seem to remember discussions about eBPF programs having certain > limitations (related to kernel Lockdown patches and Secure Boot). > Has this changed? Is running eBPF programs in stock Fedora (with > Secure Boot enabled) possible now? > > Fabio > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > <mailto:devel@xxxxxxxxxxxxxxxxxxxxxxx> > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > <mailto:devel-leave@xxxxxxxxxxxxxxxxxxxxxxx> > Fedora Code of Conduct: https://docs.fedoraproject.org/en- > US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora- > infrastructure > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
