Re: [Qemu-devel] [PATCH 0/5] ATAPI pass through v2

[Anthony Liguori <anthony@codemonkey.ws>]

Ian Jackson wrote:
> Anthony Liguori writes ("Re: [Qemu-devel] [PATCH 0/5] ATAPI pass through v2"):
>   
>> No need for a switch IMHO.  If a user is doing pass through, they ought 
>> to expect that the guest has direct access to the device.
>>     
>
> The firmware of an IDE device can usually take over complete the
> control of the host, if it chooses to and knows how.  So upgrading the
> firmware on the device is a lot more serious than just being able to
> break the device.  It would allow the guest to escape containment.
>
> So this definitely needs to be disabled by default.
>   

Pass through == escape containment.

That's generally true (even with VT-d).  There's all sorts of bad things 
you can do generating interrupt storms or physically bricking hardware.

> I disagree entirely.  The qemu process inevitably has access to an
> enormous amount of stuff that the guest shouldn't have, and in most
> cases users don't even run it as a different user.
>
> Or are you suggesting qemu should always be run in a chroot ?

As a lesser privileged user or as root heavily restricted by SELinux, yes.

>   Or a VM
> perhaps ?  qemu only safe run under Xen PV ?  I don't think the KVM
> guys are really going to like that as a security policy ...
>   

It's about layers of security.  If you design your security assuming 
that QEMU is safe, you're taking a much bigger risk than if you assume 
QEMU is hostile.

>> I'm sure something like SELinux can be used to prevent a root QEMU 
>> process from doing a firmware upgrade.
>>     
>
> *boggle*  You're not serious, are you ?
>   

Yes, I'm actually a fan of SELinux in the context of a dedicated 
virtualization system.


Regards,

Anthony Liguori