> On Feb 12, 2024, at 10:18 AM, Marius Schwarz <fedoradev@xxxxxxxxxxxx> wrote: > > Hi, > > I excuse myself if this has been already discussed, bastion ML server was blacklisted (has been removed btw). > > Short summary(for details use the source link): > > In a german developer blog article was the topic raised, that with uprobes enabled, userland apps can i.e. circumvent tls security(and other protections), > by telling the kernel to probe the function calls with the uprobes api. As this enables i.e. the hosting system of a vm or container, to track activity inside the container, trust is lost i.e. from customer to hoster. To be fair, you need to be root on the host to do this, but as it "wasn't possible before", and it is "now" ( out in a greater public ), it tends to create trust issues, just for being there*. > > As this only works with uprobes enabled and has no use case besides a developer debugging apps, the question is: With my kernel developer hat on, this is ridiculous. Of course the host of a container or VM can see what’s going on inside the container/VM, and no amount of changing Fedora’s kernel configuration will make a difference. The host can use a hypervisor or run a different kernel or use ptrace or use perf or use nsenter or look at /proc or use kprobes or use bpfttrace or use *any* bpf program with memory-reading permission [0]. This proposed change would serve to annoy Fedora users and have no other benefit. [0] it’s surprisingly poorly advertised, but, while BPF itself is nominally memory-safe, eBPF usually exposes a function that serves as a fairly complete escape hatch for reading user and kernel memory. > > Do we need this for all others out there enabled by default? > > If noone can name an app/lib that needs this outside of the C* development process, a change proposal would be wise. maybe adding a kernel boot argument switch? > > Source: http://blog.fefe.de/?ts=9b3a23b2 > > *) You may not have a clue, what security auditors tell you about "a vulnerability & it's just there, but inexploitable". I had a case 2 weeks ago, about a missing patch for the ssh-agent CVE vulnerability in fedora's openssh. Trust me, it will create trouble the more the topic is discussed in the pubic. > > > Best regards, > Marius Schwarz > -- > _______________________________________________ > 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, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
