Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket 'fd' open from outside for unix socket

[Wei Xu <wexu@redhat.com>]

On 2016年06月02日 19:38, Michal Privoznik wrote:
> On 02.06.2016 10:29, Daniel P. Berrange wrote:
>> On Thu, Jun 02, 2016 at 09:41:56AM +0200, Michal Privoznik wrote:
>>> On 01.06.2016 18:16, Wei Xu wrote:
>>>> On 2016年06月01日 00:44, Daniel P. Berrange wrote:
>>>>> On Wed, Jun 01, 2016 at 12:30:44AM +0800, wexu@redhat.com wrote:
>>>>>> From: Wei Xu <wexu@redhat.com>
>>>>>>
>>>>>> Recently I'm working on a fd passing issue, selinux forbids qemu to
>>>>>> create a unix socket for a chardev when managing VMs with libvirt,
>>>>>> because qemu don't have sufficient permissions in this case, and
>>>>>> proposal from libvirt team is opening the 'fd' in libvirt and merely
>>>>>> passing it to qemu.
>>>>>
>>>>> This sounds like a bug in libvirt, or selinux, or a mistaken
>>>>> configuration
>>>>> of the guest. It is entirely possible for QEMU to create a unix socket
>>>>> - not
>>>>> least because that is exactly what QEMU uses for its QMP monitor backend.
>>>>> Looking at your example command line, I think the issue is simply that
>>>>> you
>>>>> should be putting the sockets in a different location. ie at
>>>>> /var/lib/libvirt/qemu/$guest-vhost-user1.sock where QEMU has
>>>>> permission to
>>>>> create sockets already.
>>>> ah.. adjusting permission or file location can solve this problem, i'm
>>>> guessing maybe this is a more security concern, the socket is used as a
>>>> network interface for a vm, similar as the qcow image file, thus should
>>>> prevent it to be arbitrarily accessed.
>>>>
>>>> Michael, do you have any comment on this?
>>>
>>> I haven't seen the patches. But in libvirt we allow users to create a
>>> vhostuser interface and even specify where the socket should be placed:
>>>
>>>      <interface type='vhostuser'>
>>>        <mac address='52:54:00:ee:96:6c'/>
>>>        <source type='unix' path='/tmp/vhost1.sock' mode='server'/>
>>>        <model type='virtio'/>
>>>      </interface>
>>>
>>> The following cmd line is generated by libvirt then:
>>>
>>> -chardev socket,id=charnet1,path=/tmp/vhost1.sock,server \
>>> -netdev type=vhost-user,id=hostnet1,chardev=charnet1 \
>>> -device
>>> virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:ee:96:6c,bus=pci.0,\
>>>
>>> Now, if we accept only /var/run/openvwitch path in
>>> /interface/source/@path (or whatever path to OVS is), we don't need this
>>> and have users manually label the dir (unless already labeled). But
>>> since we accept just any path in there, we should make sure that qemu is
>>> then able to create the socket. One possible fix would be to allow qemu
>>> create sockets just anywhere in the system. This, however, brings huge
>>> security risks and it's not acceptable IMO. The other option would be
>>> that libvirt would create the socket, and pass its FD to qemu (since
>>> libvirt already is allowed to create sockets anywhere).
>>
>> There are plenty of other places where we allow arbitrary paths in the
>> XML, but which have restrictions imposed by the security drivers. Not
>> least the <channel> devices which have the exact same scenario as this
>> network device, and require use of /var/lib/libvirt/qemu as the directory
>> for the sockets. We certainly do not want to allow QEMU to create sockets
>> anywhere.
AFAIK, Vhost user is an interface for third party implementations, and 
ovs/dpdk is one of the most popular choices, if it limits the socket 
location of a fixed and unprivileged directory to qemu, actually this 
should be the default and only one option, this maybe also a security 
consideration, so we'll have no other choice but ask sys admin to 
manipulate the permission, looks accepting a safe passed in 'fd' from 
libvirt is more rigorous and convenient, i'm not sure if this is a 
typical or a corner scenario.

Daniel,
How do you think about this with a general purpose? does qemu need such 
a feature?
>>
>> I don't think we want to grant QEMU svirtt permission to create sockets
>> in the /var/run/openvswitch directory either really.IMHO, users of vhost
>> user should really be using /var/lib/libvirt/qemu, as is used for all
>> other UNIX sockets we create wrt other devices.
>
> Okay. I can live with that; but in that case we should document it
> somewhere, that we guarantee only paths under /var/lib/libvirt/ to be
> accessible and for the rest we do our best but maybe require sys admin
> intervention (e.g. to label the whole tree for a non-standard location).
>
> Michal
>