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

[Daniel P. Berrange]

On Tue, Jun 14, 2016 at 04:03:43PM +0800, Wei Xu wrote:
> On 2016年06月09日 05:48, Aaron Conole wrote:
> > Flavio Leitner <address@hidden> writes:
> > 
> > > Adding Aaron who is fixing exactly that on the OVS side.
> > > 
> > > Aaron, please see the last question in the bottom of this email.
> > > 
> > > On Wed, Jun 08, 2016 at 06:07:29AM -0400, Amnon Ilan wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Michal Privoznik" <address@hidden>
> > > > > To: "Daniel P. Berrange" <address@hidden>
> > > > > Cc: address@hidden, "amit shah" <address@hidden>,
> > > > > address@hidden, "Wei Xu" <address@hidden>,
> > > > > address@hidden
> > > > > Sent: Thursday, June 2, 2016 2:38:53 PM
> > > > > Subject: Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket
> > > > > 'fd' open from outside for unix socket
> > > > > 
> > > > > 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, address@hidden 
> > > > > > > > > wrote:
> > > > > > > > > > From: Wei Xu <address@hidden>
> > > > > > > > > > 
> > > > > > > > > > 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).
> > > > 
> > > > Does OVS has some limit for it's sockets to be only in 
> > > > /var/run/openvswitch ?
> > 
> > As of a recent commit, it can only be in /var/run/openvswitch or a
> > subdirectory therein (found in the openvswitch database).
> Aaron, thanks for your reply.
> 
> Just a question about the usage of openvswitch, in this user case when
> launching a vhostuser/dpdk via libvirt, qemu works as server mode for socket
> under /var/run/openvswitch, but per my previous test, ovs/dpdk always works
> as server mode, which means ovs will creates the socket and listening for
> connection, thus qemu works as client mode, does ovs/dpdk support working in
> client mode? which means it's qemu's duty to create the socket? and ovs will
> connect to it on demanding?

Oh, I was assuming that QEMU would be working in server mode - no wonder
we have somewhat different views :-)

If OVS is running the UNIX socket server, and QEMU is purely the client,
then that means the solution would be slightly different. In particular
libvirt would *not* do any SELinux relabelling. Instead you would have
to get an addition to the SELinux policy, to allow svirt_t type to connect
to the SELinux type associated with the openvswitch socket.

For file permissions, if the OVS socket is owned by a particular UNIX
group, you could potentially add the 'qemu' user account to that group
to grant access.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|