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

[Michal Privoznik <mprivozn@redhat.com>]

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