Re: do we need CONFIG_UPROBES=y in our kernels?
Marius Schwarz wrote: > From guest to host: you need to trust the host not to spy on you, your > data, connection targets aso. Correct. This is a fundamental principle. Users are at the mercy of the sysadmin. Programs are at the mercy of the operating system. Virtual machines are at the mercy of the host operating system. "The cloud" is just other people's computers, and those people have the power to spy on what you do on their computers. The processor vendors market so-called "secure enclaves" that are supposed to make it so that the host operating system can't see what a guest program does. Of course that means only that the vendor's firmware is the true host, so now the "host" and the guest are both at the mercy of the unfree and secretive firmware. And there have been news about firmware bugs that let attackers bypass the protection, rendering the enclaves useless. The solution is to consider security before you rent other people's computers, and keep secrets and sensitive data on your own hardware. Björn Persson pgpojY8pw6hQR.pgp Description: OpenPGP digital signatur -- ___ 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
Re: do we need CONFIG_UPROBES=y in our kernels?
Am 15.02.24 um 23:09 schrieb Kevin Kofler via devel: They should instead learn some basic concepts of security. It's about trust in integrity of system encapsulated in something else which is disrupted. From host to guest: you need to trust the guest not to ... spam, scan, hack aso. From guest to host: you need to trust the host not to spy on you, your data, connection targets aso. "not per se bad faith" kernel mechanics that can do that, do not help with trust. That's what the original author wanted to express, and here i agree. My work would also suffer, if i could not just trace a process when i need to. On the other hand, I can imagine that hardening the system against "espionage" can only help to gain that trust into computing and turn the lifes of some bad actors worse. Having talked about it, is a good start. conveniently read if they ever manage to compromise your computer. That contraption is one of the first things I disable on my computers! Agreed, for a more profane reason: it trashes the logfiles for 99.9+% of the time ;) 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
Re: do we need CONFIG_UPROBES=y in our kernels?
Roberto Ragusa wrote: > Auditors are constantly proposing disabling features and making things > inconvenient, undebuggable, inefficient and substantially annoying to > operate. > > They should instead learn some basic concepts of security. > For example: if you are running a process, even in a VM or container, you > have to trust the administrator of the host system. And that's it. +1. Disabling important debugging tools in the name of "security" is a no go. Also goes for ptrace etc. The worst invasive security nightmares actually come from the security folks themselves, e.g., auditd, which keeps a meticulous log of just about everything you do that the NSA (or other countries' equivalent) can conveniently read if they ever manage to compromise your computer. That contraption is one of the first things I disable on my computers! Kevin Kofler -- ___ 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
Re: do we need CONFIG_UPROBES=y in our kernels?
On 2/13/24 7:36 AM, Jerry James wrote: > On Mon, Feb 12, 2024 at 11:16 AM Marius Schwarz > wrote: >> 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: >> >> Do we need this for all others out there enabled by default? > > Both systemtap and bpftrace can use uprobes. Those capabilities have > been important from time to time in my job. That does not mean that > my ability to do my job should outweigh security concerns, of course, > but I think some effort should be made to find out if use of uprobes > via systemtap and bpftrace is common amongst Fedora users. "perf probe" can also define events based on uprobes, which makes them available to "perf record", "perf trace", etc. -- ___ 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
Re: do we need CONFIG_UPROBES=y in our kernels?
> On Feb 12, 2024, at 10:18 AM, Marius Schwarz 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
Re: do we need CONFIG_UPROBES=y in our kernels?
Hi, > On 12. Feb 2024, at 19:15, Marius Schwarz wrote: > > 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*. How was this not possible before? If I’m root on the host, I could always start a gdb and attach it to a process running in a container. I could also always have replaced a file in the container (e.g., the libssl.so library with an instrumented one that just writes the TLS communication in clear text into a pipe). On a kernel with /dev/mem, the host could probably have located the encryption keys directly in memory, too. It really sounds to me like the incorrect assumption here is that the host was not already able to do these things. If you don’t trust your host, look into confidential computing and confidential containers. Those also don’t solve every single problem, but they get you closer. -- Clemens Lang RHEL Crypto Team Red Hat -- ___ 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
Re: do we need CONFIG_UPROBES=y in our kernels?
On 2/12/24 7:15 PM, Marius Schwarz 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*. If I am reading this correctly, if I have a VM that's being hosted on a host kernel that has uprobes capabilities and a malicious actor with root access is controlling the host kernel, does it matter what options is the guest using if the host can simply utilize their uprobes? This hypothetical malicious hoster could also just use their own custom kernel if they were relying on Fedora's kernel. And if they are this malicious, they also can just break into your containers via regular container tools. IMO containers are at no level a reliable security sandbox without additional safeguards, this goes both for host and guest. Regards, Jarek As this only works with uprobes enabled and has no use case besides a developer debugging apps, the question is: 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
Re: do we need CONFIG_UPROBES=y in our kernels?
> > 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: > > > > Do we need this for all others out there enabled by default? > > Both systemtap and bpftrace can use uprobes. Those capabilities have > been important from time to time in my job. That does not mean that > my ability to do my job should outweigh security concerns, of course, > but I think some effort should be made to find out if use of uprobes > via systemtap and bpftrace is common amongst Fedora users. And unfortunately it's not buildable as a module, I suspect there's some form of capabilities around it, I'm not sure if that can be tightened. -- ___ 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
Re: do we need CONFIG_UPROBES=y in our kernels?
On Mon, Feb 12, 2024 at 11:16 AM Marius Schwarz wrote: > 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: > > Do we need this for all others out there enabled by default? Both systemtap and bpftrace can use uprobes. Those capabilities have been important from time to time in my job. That does not mean that my ability to do my job should outweigh security concerns, of course, but I think some effort should be made to find out if use of uprobes via systemtap and bpftrace is common amongst Fedora users. -- Jerry James http://www.jamezone.org/ -- ___ 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
Re: do we need CONFIG_UPROBES=y in our kernels?
On 2/12/24 19:15, Marius Schwarz wrote: 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*. [...] *) 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. Auditors are constantly proposing disabling features and making things inconvenient, undebuggable, inefficient and substantially annoying to operate. They should instead learn some basic concepts of security. For example: if you are running a process, even in a VM or container, you have to trust the administrator of the host system. And that's it. Regards. -- Roberto Ragusamail at robertoragusa.it -- ___ 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
do we need CONFIG_UPROBES=y in our kernels?
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: 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
