New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Hi,
deinstalling qemu-guest-agent is completely pointless if you do not at the same time install your system manually and encrypt it.
It all boils down to:
Either you trust your hoster, then deinstalling qemu-guest-agent will only harm YOU as a customer as some UI functions of the hoster and also functions like snapshots will either stop working or work less optimal
Or you dont trust your hoster, then your hoster can still any time simply mount your data / partition and extract it the way he wants it. He can easily do that without that you will notify it using snapshots or what ever similar. The only way to render this pointless will be encryption on filesystem level.
And even then, your key is in your RAM once the system was started. With enough criminal energy your hoster will be able to extract it from there. So even then he can access your files.
The only real way to avoid this all would be to encrypt your files without real time encryption but with a one time encryption ( like giving a password on your what ever files ).
But then you can only access them if you decrypt them by entering the password when you need it. Using a wrapper to handle this automatically for you will again bring the key into the RAM this or another way.
So all in all:
Either you trust or not. If you dont trust, dont host with this hoster.
The only way to really avoid this is to take some bare metal where the hoster can not easily get the RAM content so you could work with a filesystem level real time encryption.
And in all this story is the qemu-guest-agent actually your very smallest problem....
No. Not as simple. "LUKS unlocked" doesn't mean that the disk content is all at once unencrypted. Just that the running VM kernel knows how to unencrypt the data it just read. And that of course depends on the encryption key stored in RAM, so you still need to dump and search for that, which you hoped to avoid. Then decode the data from disk yourself, using that key.
As described above, also not correct.
This is very insightful and thank you for correcting me. Makes me feel a bit more at ease, though I guess there's already 6 million backdoors to my chinese CCP sponsored vepees
Then we are all doomed.
I think of it as security, in case my server’s data gets dumped somewhere then that it means it’s not accessible to anyone.
If I wanted to pick something secure it would probably be one of the big German providers along with LUKS. I feel like they are more likely to have some sort of audit system in place that employees would take seriously.
I hate german companies with a burning passion, but I'll give +1 for that.
a few providers (including us) support enabling AMD SEV on VM which encrypts the VM memory. You can't take snapshot when SEV is enabled.
@raindog308 wrote a good article about this here: https://lowendbox.com/blog/how-private-is-your-hosted-data-really-even-that-encrypted-stuff/
There's a related thread linked in the article as well.
I think it's important to have this conversation, and have more people aware of the security and privacy implications of hosting. I have reasonable trust with the providers I order from, but it's good to make an informed decision and take precautions as needed.
(a) seems to be also related to the systemd cancer, yuck.
(b) of bloody course a provider who after all has full access to the node can, if evil and ill-willed enough - or with LEA agents breathing down his neck and potentially threatening his business - fully get at, look at, and/or even change each and every byte on a virtual machine.
So even installing from ISO does NOT really protect you, but it at least makes it less easy and comfortable to eavesdrop on your VM, which also makes it less likely that some evil employee "by accident" looks into your VPS.
And no disk/partition encryption does not really protect you completely because either the disk/partition is decrypted when starting your VM or the key is somewhere in memory.
(c) Btw the same holds largely true on a dedi as well. Simple rule: anyone with physical access to your server can, provided he/she has sufficient knowledge and criminal energy (or LEA), get at, look at, and change your data. Plus obviously there is plenty of questionable IPMI stuff lurking.
TL;DR Do not assume that only you can get at your data, no matter whether dedi or VM. The relevant point is (worst case physical) access to the server.
But you can somewhat minimize the risk by installing from ISO.
But then, is there really anything really safe and secure in IT nowadays?
(This is in no way directed at Advin. He just happened to say something relevant and to trigger my post. The fact that he openly states that basically nothing really protects you IMO suggests that he is a decent guy)
Pardon me, but NO. While the idea is nice and probably was well intended, SEV & friends are broken too.
Same here. I use them, very secure, but I don’t like them they are assuoles
Nice search on google : qemu-ga security
hate to disappoint you but those results are influenced by your own browser activity
and with range from past week ofc it will be top
Years ago, we had an encrypted centos VM in ESXi. I used VMWares converter using root password to migrate to another ESXi server. It was no longer encrypted.
But I think the standard rule is, if you got root password, you got it all anyway.
You could provide a link to actually be helpful instead of answering incorrectly "NO" to both his true statements.
So? The "VMWare converter" script didn't know it was supposed to also create LUKS at the destination, likely just sshed into the source, then rsynced its filesystem which was of course mounted and readable to you when you ssh as root. Is that a ding on the LUKS security or what relevance that has.
No, more of a PSA (I was fully expecting the migrated VM to boot to encryption prompt. That would need to be an offline migration through ESXi). Meant to show that if someone has your root password, LUKS ain't going to help in a running machine. So you still need all the usual protections for root.
just don’t snoop around my 500gb files and u gud
this shit I could not care less
Early implementations (pre Zen3) like SEV and SEV-ES are broken. SEV-SNP (Zen3+) and TDX still stand. You can make tens of thousands USDs in bounty from AMD and/or Intel (for TDX) if you broke SEV-SNP and/or TDX.
Unfortunately all the major offerings of confidential computing are undermined by providers, according to a recent survey paper (sponsored by German gov): https://arxiv.org/abs/2503.08256
"Our findings reveal that all major cloud providers retain control over critical parts of the trusted software stack and, in some cases, intervene in the standard remote attestation process. This directly contradicts their claims of delivering confidential computing, as the model fundamentally excludes the cloud provider from the set of trusted entities".
Will providers interested in providing confidential computing as intended, please respond positively either here or pm.
I'd put that somewhat differently: The newer ones aren't broken yet or at least not known to be broken, which isn't the same. Especially if one wants the bounty usually a "hold still and stay quiet" period has to be accepted. Which I can understand, after all we all are better off when it's published only once the manufacturer has a chance to provide mitigation.
But it also means that "not known to be broken" != "not broken and safe".
Also note the word "trust" in the title ...
As long as SEV-SNP could be implemented more trustworthy than your typical homelabs/laptops, which probably have way bigger combined hardware and software attack surfaces, it's worth our trust with some (not absolute of course) confidence.
The fact that none of the major providers does it properly could imply that confidential computing in the hands of average users might be too powerful for mass surveillance.
Could qemu-ga and other qemu files lead to prompt injection evasion ?
Something interesting to read with this "skynet malware" in windows env.
Source : Checkpoint Research, June 25, 2025
Are you saying that there aren't enough virtualization-trained technicians at providers to implement VPS servers?
According to the paper I cited above, the failure to implement CC properly across the major providers "arises from various factors, including legal obligations, operational constraints, and economic incentives, which ultimately influence how the architectures of the offered solutions are being designed". See section 5.5 for details.
OTOH, it's actually fairly straightforward to implement CC as intended using 100% open source software on dedicated Zen3+ EPYC servers. It's interesting that none of the providers here even expressed any interest to provide the most trustworthy computing option that is already widely used in finance, healthcare, and defense sectors.
Here section 5.5 for people
Turn the wheel again. Do I understand that it tends to (or ends) to no more privacy in fact ?
There are indeed strong corp & gov "incentives" to encroach on people's privacy. OTOH, the CC technology so far can already enable freedom/privacy loving people to achieve much better privacy than before. It only takes the will of people to implement it. The lack of provider interest here is kinda disappointing.
Freedom and privacy is a matter of choice. More than ever.
Some Other Things are HERE