From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCjKF-0007Eo-ND for qemu-devel@nongnu.org; Tue, 14 Jun 2016 04:03:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCjKA-0006an-28 for qemu-devel@nongnu.org; Tue, 14 Jun 2016 04:03:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47180) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCjK9-0006Zx-Pl for qemu-devel@nongnu.org; Tue, 14 Jun 2016 04:03:49 -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 BE84A63163 for ; Tue, 14 Jun 2016 08:03:48 +0000 (UTC) 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> From: Wei Xu Message-ID: <575FBA5F.50201@redhat.com> Date: Tue, 14 Jun 2016 16:03:43 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed 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 , Flavio Leitner Cc: Amnon Ilan , Michal Privoznik , "Daniel P. Berrange" , qemu-devel@nongnu.org, amit shah , jasowang@redhat.com, armbru@redhat.com On 2016=E5=B9=B406=E6=9C=8809=E6=97=A5 05:48, Aaron Conole wrote: > Flavio Leitner 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" >>>> 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 >>>> >>>> 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. Berrange = wrote: >>>>>>>> On Wed, Jun 01, 2016 at 12:30:44AM +0800, wexu@redhat.com wrote: >>>>>>>>> From: Wei Xu >>>>>>>>> >>>>>>>>> Recently I'm working on a fd passing issue, selinux forbids qem= u to >>>>>>>>> create a unix socket for a chardev when managing VMs with libvi= rt, >>>>>>>>> because qemu don't have sufficient permissions in this case, an= d >>>>>>>>> proposal from libvirt team is opening the 'fd' in libvirt and m= erely >>>>>>>>> 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 simpl= y 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 use= d 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 creat= e a >>>>>> vhostuser interface and even specify where the socket should be pl= aced: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 nee= d this >>>>>> and have users manually label the dir (unless already labeled). Bu= t >>>>>> since we accept just any path in there, we should make sure that q= emu 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 (sin= ce >>>>>> 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. 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. >>>>> >>>>> I don't think we want to grant QEMU svirtt permission to create soc= kets >>>>> 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 a= ll >>>>> 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 b= e >>>> accessible and for the rest we do our best but maybe require sys adm= in >>>> intervention (e.g. to label the whole tree for a non-standard locati= on). >>> >>> Does OVS has some limit for it's sockets to be only in /var/run/openv= switch ? > > 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=20 launching a vhostuser/dpdk via libvirt, qemu works as server mode for=20 socket under /var/run/openvswitch, but per my previous test, ovs/dpdk=20 always works as server mode, which means ovs will creates the socket and=20 listening for connection, thus qemu works as client mode, does ovs/dpdk=20 support working in client mode? which means it's qemu's duty to create=20 the socket? and ovs will connect to it on demanding? > >>> Flavio, do you know? >>> If not, we are good as it is today with /var/lib/libvirt/qemu, right? > > 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) > > 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 :). > > Hope this helps, > -Aaron >