Are secrets hidden from admins too - ?
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 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.
yes, my bad I was not clear on that - yes private & ephemeral. Those 'secrets' virsh says cannot "get" back to me, even to me root, so that's good. So here, I wonder', if there is a technique which a malicious root could use to a secret.
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.
"Launch Security" - I was not even aware of. Busy with admin stuff and not checking changelogs, bad me again. Thanks for that.
And if answer is yes then - do you have any best practices for storing & managing of those secrets?
many thanks, L.
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.
Last one - would by any chance you/Redhat have a schedule for Libvirt with SEV to go into RHELs/CentOS Stream? 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.
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.
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.
On 24/08/2021 08:06, Erik Skultety wrote:
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.
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. Any chance you(with/via Redhat) could push in something more on pair with what is in RHEL, as you explained? At present CentOS Stream seems to have mere 6.0.0.x version.
many thanks, L.
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.
On Tue, Aug 31, 2021 at 12:57:28PM +0100, lejeczek wrote: ...
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. Any chance you(with/via Redhat) could push in something more on pair with what is in RHEL, as you explained? At present CentOS Stream seems to have mere 6.0.0.x version.
many thanks, L.
Sorry, for such a late notice. Well, only the base Stream has libvirt 6.0.0. Then there's the Advanced Virt "stream" which can be installed with: centos-release-advanced-virtualization.noarch The libvirt version available through this channel is 7.6.0 Regards, Erik
participants (3)
-
Erik Skultety -
lejeczek -
Martin Kletzander