> On Feb 12, 2024, at 10:18 AM, Marius Schwarz <fedora...@cloud-foo.de> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
