From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCsU4-0000r1-ID for qemu-devel@nongnu.org; Tue, 14 Jun 2016 13:50:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCsTz-0005Uq-Ir for qemu-devel@nongnu.org; Tue, 14 Jun 2016 13:50:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCsTz-0005Ul-Au for qemu-devel@nongnu.org; Tue, 14 Jun 2016 13:50:35 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 CC51072093 for ; Tue, 14 Jun 2016 17:50:34 +0000 (UTC) Received: from wei-thinkpad.nay.redhat.com (vpn1-6-69.pek2.redhat.com [10.72.6.69]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5EHoWU5023132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Jun 2016 13:50:34 -0400 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> <575FBA5F.50201@redhat.com> <20160614081708.GB4310@redhat.com> From: Wei Xu Message-ID: <576043E7.4070809@redhat.com> Date: Wed, 15 Jun 2016 01:50:31 +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: qemu-devel@nongnu.org On 2016=E5=B9=B406=E6=9C=8814=E6=97=A5 22:23, Aaron Conole wrote: > "Daniel P. Berrange" writes: > >> On Tue, Jun 14, 2016 at 04:03:43PM +0800, Wei Xu wrote: >>> 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. 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 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 moni= tor >>>>>>>>>>> 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 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). >>>>>>>> >>>>>>>> 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 >>>>>>>> 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 fo= r all >>>>>>>> other UNIX sockets we create wrt other devices. >>>>>>> >>>>>>> Okay. I can live with that; but in that case we should document i= t >>>>>>> somewhere, that we guarantee only paths under /var/lib/libvirt/ t= o 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 loc= ation). >>>>>> >>>>>> 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 whe= n >>> 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 wor= king in >>> client mode? which means it's qemu's duty to create the socket? and o= vs will >>> connect to it on demanding? >> >> Oh, I was assuming that QEMU would be working in server mode - no wond= er >> we have somewhat different views :-) >> >> If OVS is running the UNIX socket server, and QEMU is purely the clien= t, >> then that means the solution would be slightly different. In particula= r >> 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 con= nect >> to the SELinux type associated with the openvswitch socket. > > I agree, this is a good MAC solution. OK. > >> 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. > > I actually would propose making a new vhost group, and adding the qemu > user account and openvswitch user accounts to that group. That way red= uces > pollution into other aspects of each process' function. Michal, Can we fix it with this as a replacement? One of my concerns about the patch is looks there are a few other places=20 in system which need 'fd' like sockets, therefore each needs a new 'fd'=20 parameter in command line, this maybe not a clean and concise way, i=20 think qemu_open() proposed by Eric is better to generally solve these=20 kind of issues, maybe we can consider enhancing it along that direction=20 in the future, what's your opinion? > > -Aaron > >> >> Regards, >> Daniel >