From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAw55-0000jT-D5 for qemu-devel@nongnu.org; Thu, 09 Jun 2016 05:16:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAw50-0001p6-R9 for qemu-devel@nongnu.org; Thu, 09 Jun 2016 05:16:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAw50-0001ow-Ii for qemu-devel@nongnu.org; Thu, 09 Jun 2016 05:16:46 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 15FD65CE for ; Thu, 9 Jun 2016 09:16:45 +0000 (UTC) Date: Thu, 9 Jun 2016 10:16:40 +0100 From: "Daniel P. Berrange" Message-ID: <20160609091640.GB7218@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> <1277078136.58487083.1465380449805.JavaMail.zimbra@redhat.com> <20160608212738.GH3073@plex> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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: Aaron Conole Cc: Flavio Leitner , Amnon Ilan , Michal Privoznik , qemu-devel@nongnu.org, amit shah , jasowang@redhat.com, Wei Xu , armbru@redhat.com On Wed, Jun 08, 2016 at 05:48:57PM -0400, Aaron Conole wrote: > Flavio Leitner writes: >=20 > > 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: > >>=20 > >>=20 > >> ----- Original Message ----- > >> > From: "Michal Privoznik" > >> > To: "Daniel P. Berrange" > >> > Cc: qemu-devel@nongnu.org, "amit shah" , > >> > jasowang@redhat.com, "Wei Xu" , > >> > armbru@redhat.com > >> > 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 > >> >=20 > >> > 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. Berran= ge wrote: > >> > >>>> On Wed, Jun 01, 2016 at 12:30:44AM +0800, wexu@redhat.com wro= te: > >> > >>>>> From: Wei Xu > >> > >>>>> > >> > >>>>> Recently I'm working on a fd passing issue, selinux forbids = qemu to > >> > >>>>> create a unix socket for a chardev when managing VMs with li= bvirt, > >> > >>>>> because qemu don't have sufficient permissions in this case,= and > >> > >>>>> proposal from libvirt team is opening the 'fd' in libvirt an= d 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 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 prob= lem, 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, th= us 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 cr= eate a > >> > >> vhostuser interface and even specify where the socket should be= placed: > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> The following cmd line is generated by libvirt then: > >> > >> > >> > >> -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= :6c,bus=3Dpci.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 tha= t qemu is > >> > >> then able to create the socket. One possible fix would be to al= low qemu > >> > >> create sockets just anywhere in the system. This, however, brin= gs huge > >> > >> security risks and it's not acceptable IMO. The other option wo= uld be > >> > >> that libvirt would create the socket, and pass its FD to qemu (= since > >> > >> 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= . Not > >> > > least the devices which have the exact same scenario a= s 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 creat= e sockets > >> > > anywhere. > >> > >=20 > >> > > 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 fo= r all > >> > > other UNIX sockets we create wrt other devices. > >> >=20 > >> > 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 a= dmin > >> > intervention (e.g. to label the whole tree for a non-standard loca= tion). > >>=20 > >> Does OVS has some limit for it's sockets to be only in /var/run/open= vswitch ? >=20 > As of a recent commit, it can only be in /var/run/openvswitch or a > subdirectory therein (found in the openvswitch database). >=20 > >> Flavio, do you know? > >> If not, we are good as it is today with /var/lib/libvirt/qemu, right= ? >=20 > Probably not. There are other issues as well. From a DAC perspective > (so forgetting selinux at the moment), qemu and ovs run as different > users. This will mean that when ovs creates the unix domain socket > file, qemu will not be allowed to actually open it properly. I have a > commit I'm trying to get upstream for that particular issue (see > bz:1281911 and upstream list discussion: > http://openvswitch.org/pipermail/dev/2016-May/071453.html > and > http://openvswitch.org/pipermail/dev/2016-June/071978.html) >=20 > Ansis is (I think) attacking this from the selinux/MAC side. It would > be great to hear from users, libvirt folks, or anyone else in that > thread to help push it to a conclusion one way or another (even if the > approach that I've proposed is crap and wrong - then say it there :). NB, that libvirt is designed from a general POV, rather than tailored to any single application. For all resources that are file based, libvirt should be changing ownership and setting SELinux labels to grant QEMU access. This is something we need to fix in libvirts vhostuser handling regardless of what openvswitch is doing. 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 :|