Are secrets hidden from admins too - ?

lejeczek peljasz at yahoo.co.uk
Tue Aug 31 11:57:28 UTC 2021



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.
>>>
>>> [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.
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.
>>>>




More information about the libvirt-users mailing list