From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8kWi-0008NW-QX for qemu-devel@nongnu.org; Fri, 03 Jun 2016 04:32:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8kWe-0005OZ-7p for qemu-devel@nongnu.org; Fri, 03 Jun 2016 04:32:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8kWd-0005OD-W5 for qemu-devel@nongnu.org; Fri, 03 Jun 2016 04:32:16 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 861F47DCCF for ; Fri, 3 Jun 2016 08:32:15 +0000 (UTC) Date: Fri, 3 Jun 2016 09:32:11 +0100 From: "Daniel P. Berrange" Message-ID: <20160603083211.GA13827@redhat.com> Reply-To: "Daniel P. Berrange" References: <1464712247-11655-1-git-send-email-wexu@redhat.com> <20160531164448.GE21628@redhat.com> <574F0A7B.5030401@redhat.com> <01045d4a-f03d-9f0d-deeb-4927446bb894@redhat.com> <20160602082904.GD9481@redhat.com> <297e40a1-9df0-cd85-68a1-b4ef5479f8bf@redhat.com> <575075C4.2030202@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <575075C4.2030202@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket 'fd' open from outside for unix socket List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wei Xu Cc: Michal Privoznik , qemu-devel@nongnu.org, amit.shah@redhat.com, jasowang@redhat.com, armbru@redhat.com On Fri, Jun 03, 2016 at 02:07:00AM +0800, Wei Xu wrote: > On 2016=E5=B9=B406=E6=9C=8802=E6=97=A5 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=E5=B9=B406=E6=9C=8801=E6=97=A5 00:44, Daniel P. Berrang= e wrote: > > > > > > On Wed, Jun 01, 2016 at 12:30:44AM +0800, wexu@redhat.com wro= te: > > > > > > > From: Wei Xu > > > > > > >=20 > > > > > > > Recently I'm working on a fd passing issue, selinux forbids= qemu to > > > > > > > create a unix socket for a chardev when managing VMs with l= ibvirt, > > > > > > > because qemu don't have sufficient permissions in this case= , and > > > > > > > proposal from libvirt team is opening the 'fd' in libvirt a= nd merely > > > > > > > passing it to qemu. > > > > > >=20 > > > > > > 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 un= ix socket > > > > > > - not > > > > > > least because that is exactly what QEMU uses for its QMP moni= tor backend. > > > > > > Looking at your example command line, I think the issue is si= mply 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 probl= em, i'm > > > > > guessing maybe this is a more security concern, the socket is u= sed as a > > > > > network interface for a vm, similar as the qcow image file, thu= s should > > > > > prevent it to be arbitrarily accessed. > > > > >=20 > > > > > Michael, do you have any comment on this? > > > >=20 > > > > I haven't seen the patches. But in libvirt we allow users to crea= te a > > > > vhostuser interface and even specify where the socket should be p= laced: > > > >=20 > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > The following cmd line is generated by libvirt then: > > > >=20 > > > > -chardev socket,id=3Dcharnet1,path=3D/tmp/vhost1.sock,server \ > > > > -netdev type=3Dvhost-user,id=3Dhostnet1,chardev=3Dcharnet1 \ > > > > -device > > > > virtio-net-pci,netdev=3Dhostnet1,id=3Dnet1,mac=3D52:54:00:ee:96:6= c,bus=3Dpci.0,\ > > > >=20 > > > > Now, if we accept only /var/run/openvwitch path in > > > > /interface/source/@path (or whatever path to OVS is), we don't ne= ed this > > > > and have users manually label the dir (unless already labeled). B= ut > > > > 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 allo= w qemu > > > > create sockets just anywhere in the system. This, however, brings= huge > > > > security risks and it's not acceptable IMO. The other option woul= d be > > > > that libvirt would create the socket, and pass its FD to qemu (si= nce > > > > libvirt already is allowed to create sockets anywhere). > > >=20 > > > There are plenty of other places where we allow arbitrary paths in = the > > > XML, but which have restrictions imposed by the security drivers. N= ot > > > least the devices which have the exact same scenario as t= his > > > network device, and require use of /var/lib/libvirt/qemu as the dir= ectory > > > for the sockets. We certainly do not want to allow QEMU to create s= ockets > > > 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 s= hould > 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 manip= ulate > the permission, looks accepting a safe passed in 'fd' from libvirt is m= ore > 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 desc= ribe is related to the SELinux policy as it currently exists. It is possible t= o 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 libv= irt to enforce the location. There should rarely be any need to do this thoug= h, hence why we suggest that apps use /var/lib/libvirt/qemu by default, unle= ss they have specific requirements and wish to extend the SELinux policy Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|