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@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
