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

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

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 :|