Hi guys. On a remote & "shared" systems - are private secrets completely 100% safe? Can root get to those? (naturally excluding hacking of unknown bugs & exploits and theories such as "no computer system is ultimately safe")

And if answer is yes then - do you have any best practices for storing & managing of those secrets? many thanks, L.

On Mon, Aug 09, 2021 at 11:48:11AM +0100, lejeczek wrote: > Hi guys. > > On a remote & "shared" systems - are private secrets > completely 100% safe? Can root get to those? > (naturally excluding hacking of unknown bugs & exploits and > theories such as "no computer system is ultimately safe") > Well, the secret needs to be kept somewhere.  The most secure you can get with secrets is the ephemeral ones, but those still need to be kept in memory.  You could encrypt them, but then you would need to provide the decryption passphrase or key when you want to use them and that would be like providing the secret itself anyway.  Even thought there are some limitations to unlimited memory access in Linux when someone has root access you have to assume they have access to what the system has access too. The best you can do to mitigate that is using something like Intel SGX, AMD SEV and such like.  There is Launch Security [0] in libvirt, but I think it only supports SEV and something on s390.  But I do not have any experience with those. [0] https://libvirt.org/formatdomain.html#id113

> And if answer is yes then - do you have any best practices > for storing & managing of those secrets? > > many thanks, L. >

On Mon, Aug 16, 2021 at 08:01:27PM +0100, lejeczek wrote: > > On 16/08/2021 10:32, Martin Kletzander wrote: >> On Mon, Aug 09, 2021 at 11:48:11AM +0100, lejeczek wrote: >>> Hi guys. >>> >>> On a remote & "shared" systems - are private secrets >>> completely 100% safe? Can root get to those? >>> (naturally excluding hacking of unknown bugs & exploits and >>> theories such as "no computer system is ultimately safe") >>> >> Well, the secret needs to be kept somewhere.  The most secure you can >> get with secrets is the ephemeral ones, but those still need to be kept >> in memory.  You could encrypt them, but then you would need to provide >> the decryption passphrase or key when you want to use them and that >> would be like providing the secret itself anyway.  Even thought there >> are some limitations to unlimited memory access in Linux when someone >> has root access you have to assume they have access to what the system >> has access too. >> >> The best you can do to mitigate that is using something like Intel SGX, >> AMD SEV and such like.  There is Launch Security [0] in libvirt, but I >> think it only supports SEV and something on s390.  But I do not have any >> experience with those. >> >> [0] https://libvirt.org/formatdomain.html#id113 >> > Last one - would by any chance you/Redhat have a schedule for Libvirt with > SEV to go into RHELs/CentOS Stream? TL;DR It's been there for a while, we added SEV support in libvirt 6.5.0 and the libvirt version in current RHEL-8 is 7.0.0. I don't remember (even if I could I could not discuss it) the strategy, but CentOS Stream 8 will likely have a libvirt version >7.0.0.

Note that there are essentially 3 "flavours" of SEV: SEV, SEV-ES, SEV-SNP. The main difference is in the underlying HW changes; from libvirt's POV SEV and SEV-ES are identical, but neither QEMU nor libvirt support SEV-SNP fully yet - the problem here is the secure state attestation process which is still under development. What that means for end users is that they can create memory encrypted guests the same way as with the other SEV flavours, but they're still unable to verify that the guest hasn't been tampered with by a malicious QEMU or platform owner or whatnot just before it was launched. Erik > I know one can get that via/from oVirt repos, but that for me would not > work. > thanks, L. >>> And if answer is yes then - do you have any best practices >>> for storing & managing of those secrets? >>> >>> many thanks, L. >>>