11–20 of 46 posts
>eBPF programs can’t access arbitrary kernel memory. Instead the kernel provides functions to get at some restricted subset of things. I must finally becoming a security pessimist when I read those sentences and the first thing I think is: these statements will not age well.
If there's a physical possibility, it's just a matter of time before someone finds a way, as was proved by the CPU cache bugs leaking information.
Is PDF link broken in the blog ?
Earlier quoted context omitted.
The BPF capability should really only be given to root. I don't think it really gives any new attack surface. All I could see is it giving black-hats an easier interface to "kernel-level-fuckery".
It’s not an easier interface. It’s much easier to write kernel modules than to mess around with eBPF.
>...
>seccomp / landlock security things
Landlock does not use *BPF.
Seccomp can only use BPF at this point, not eBPF (though there has been some work on it).
Earlier quoted context omitted.
It’s not an easier interface. It’s much easier to write kernel modules than to mess around with eBPF.
Easier to get started maybe, but there's something to be said for the 'ease' of having to worry a lot less about crashing the kernel you're working on.
>eBPF programs can’t access arbitrary kernel memory. Instead the kernel provides functions to get at some restricted subset of things. I must finally becoming a security pessimist when I read those sentences and the first thing I think is: these statements will not age well.
I wouldn't be surprised if it becomes entirely root-only by default soon, if it isn't already.
Earlier quoted context omitted.
That's definitely a security professional's read :) "Isn't supposed to be able to" is a lot longer and distracting vs the oversimplification-for-sake-of-understanding of "can't". As far as it being proven wrong though - that's already happened, eg CVE-2021-29154 https://blog.kernelcare.com/vulnerability/specially-crafted-...
That's fair. I understand that in the ideal world, it would be "can't." I guess my concern is that the wording kind of hand waves away any potential security issues, when people interested in this tech should absolutely be made aware of them.
BPF is indeed a pretty interesting technology. As the knowledge about it becomes more widespread, I anticipate that we will unlock some new capabilities both in terms of tracing. Brendan Gregg's book ( https://www.brendangregg.com/bpf-performance-tools-book.html ) serves as a good intro to this, although you probably only need to read a small chunk of it as a lot of it is reference-book-style material. The author's m…
Sorry, I'm a little confused why this would be necessary? Like, sure, it's a nice to have on a CI as a basic sanity check but if you just invoke mlockall you'll end up with everything wired down and you're good to go regardless?
Earlier quoted context omitted.
It’s not an easier interface. It’s much easier to write kernel modules than to mess around with eBPF.
Easier to get started maybe, but there's something to be said for the 'ease' of having to worry a lot less about crashing the kernel you're working on.