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

[Daniel P. Berrange]

On Fri, Jun 03, 2016 at 02:07:00AM +0800, Wei Xu wrote:
> 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, 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.
> 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.

Libvirt doesn't limit the socket locations because the restriction I describe
is related to the SELinux policy as it currently exists. It is possible to
further extend the SELinux policy to allow other locations to be used if
it makes sense for particular use cases, hence it would be wrong for libvirt
to enforce the location. There should rarely be any need to do this though,
hence why we suggest that apps use /var/lib/libvirt/qemu by default, unless
they have specific requirements and wish to extend the SELinux policy

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