[libvirt] AMD SEV's /dev/sev permissions and probing QEMU for capabilities

[Martin Kletzander]

On Fri, Jan 18, 2019 at 11:17:11AM +0000, Daniel P. Berrangé wrote:
>On Fri, Jan 18, 2019 at 12:11:50PM +0100, Martin Kletzander wrote:
>> On Fri, Jan 18, 2019 at 10:16:38AM +0000, Daniel P. Berrangé wrote:
>> > I've just realized there is a potential 3rd solution. Remember there is
>> > actually nothing inherantly special about the 'root' user as an account
>> > ID. 'root' gains its powers from the fact that it has many capabilities
>> > by default.  'qemu' can't access /dev/sev because it is owned by a
>> > different user (happens to be root) and 'qemu' does not have capabilities.
>> >
>> > So we can make probing work by using our capabilities code to grant
>> > CAP_DAC_OVERRIDE to the qemu process we spawn. So probing still runs
>> > as 'qemu', but can none the less access /dev/sev while it is owned
>> > by root.  We were not using 'qemu' for sake of security, as the probing
>> > process is not executing any untrusthworthy code, so we don't  loose any
>> > security protection by granting CAP_DAC_OVERRIDE.
>> >
>>
>> IMHO CAP_DAC_OVERRIDE is a lot, especially on systems without SELinux.
>
>Probing of QEMU capabilities is not a security critical task. QEMU is
>run with "-machine none" so does not even create the virtual machine
>hardware, nor have any guest image that it would run. All it is running
>is the QEMU class initialization code. The only way for that to act in
>a malicious way is for a backdoor to have been inserted when QEMU was
>built by the OS vendor, or fo the QEMU binary on disk to have been
>replaced by something malcious (which would require root privileges
>itself).
>

So you are trying to protect from buggy qemu with malicious guest, not really a
malicious qemu.  I got confused as SEV is trying to protect against
untrustworthy host including binaries like qemu.  OK

>
>We must of coure *NEVER* give CAP_DAC_OVERRIDE to a QEMU that is running
>the real, untrustworty, end user VM.
>
>Regards,
>Daniel
>-- 
>|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
>|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
>|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190118/982751cb/attachment-0001.sig>