Locked-down TLS is a pain for testers, because, of course, the whole idea is preventing third parties from seeing plaintext. But that's what app testers need to do (usually, to get enough information to write their own tooling-grade clients and servers to use to probe vulnerabilities with). There's a bunch of different tools people use for this purpose; Frida is probably the best-known example, for mobile and native clients.
But if your target under test is Linux, modern eBPF gives you enough tooling to capture plaintext without directly instrumenting binaries, which is handy.
This isn't, like, per se a vulnerability; they're not saying it is.
"Defeating" is a really poor choice of verb in the title for a post that isn't claiming a vulnerability.
As you say, quarkslab's tool (Peetch) can be a user-friendly alternative to Wireshark and SSL logs workaround.
I wouldn't characterize it as "defeating TLS encryption" either, because it's not like you're decrypting traffic someplace other than on the host you already have privileged access to (and assuming you already have MITM capability, which is by no means assured).
It's meant more as a showcase of how eBPF can be applied to a technical challenge, as opposed to the author claiming they fundamentally broke TLS.
I do point out that is editorializing on submitters part, the actual subtitle is "A security focused introduction to eBPF", which is much more descriptive of the content
As someone fairly new to these concepts, this was a fantastic read. The title just needs to be updated.
This is not entirely true.
SELinux does allow you to lock down certain actions while leaving root access available.
And of course you can configure selinux to prevent root user from disabling selinux.
So you might have root access and the game would not be over.
Please correct me if I'm wrong here (I likely am), but isn't the fundamental design of eBPF engineered to allow injection of code into the kernel pertaining to MORE than just network-level stuff? Sure we see it at the network level primarily right now, but what's stopping that from being used for all kinds of things?
Short of very specific server-side applications, I see that as all risk, and little-to-no reward, so I'd like it disabled, especially on my personal workstation. Thing is, I know next to jack $#!t about eBPF, so I'm not sure what'll happen to my network (or other stuff?) if I just throw down and do that.
Any thoughts? Feasible? Bad idea(TM)?
There are other tools that use eBPF to mitigate specific Linux kernel vulnerabilities, or to do Linux kernel observation/tracing.
sudo apt-get install bpfcc-tools
Also, this might be useful: https://embracethered.com/blog/posts/2021/offensive-bpf-snif...
eBPF is used in systemd's firewall code though, which allows filtering the IP addresses a service can contact. If this feature is not needed, eBPF can probably be disabled without impacting the other sandboxing features of systemd.