From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCpFK-0004KB-Ar for qemu-devel@nongnu.org; Tue, 14 Jun 2016 10:23:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCpFE-0001b1-6A for qemu-devel@nongnu.org; Tue, 14 Jun 2016 10:23:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCpFD-0001ad-UV for qemu-devel@nongnu.org; Tue, 14 Jun 2016 10:23:08 -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 8319764365 for ; Tue, 14 Jun 2016 14:23:07 +0000 (UTC) From: Aaron Conole 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> Date: Tue, 14 Jun 2016 10:23:05 -0400 In-Reply-To: <20160614081708.GB4310@redhat.com> (Daniel P. Berrange's message of "Tue, 14 Jun 2016 09:17:09 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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: "Daniel P. Berrange" Cc: Wei Xu , Flavio Leitner , Amnon Ilan , Michal Privoznik , qemu-devel@nongnu.org, amit shah , jasowang@redhat.com, armbru@redhat.com "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: >> >=20 >> > > Adding Aaron who is fixing exactly that on the OVS side. >> > >=20 >> > > Aaron, please see the last question in the bottom of this email. >> > >=20 >> > > 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 wro= te: >> > > > > > > On 01.06.2016 18:16, Wei Xu wrote: >> > > > > > > > On 2016=E5=B9=B406=E6=9C=8801=E6=97=A5 00:44, Daniel P. Be= rrange wrote: >> > > > > > > > > On Wed, Jun 01, 2016 at 12:30:44AM +0800, wexu@redhat.co= m wrote: >> > > > > > > > > > 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 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. >> > > > > > > > >=20 >> > > > > > > > > This sounds like a bug in libvirt, or selinux, or a mist= aken >> > > > > > > > > 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. i= e 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. >> > > > > > > >=20 >> > > > > > > > Michael, do you have any comment on this? >> > > > > > >=20 >> > > > > > > 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: >> > > > > > >=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:6c,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 need this >> > > > > > > and have users manually label the dir (unless already labele= d). 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, b= rings 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 qem= u (since >> > > > > > > libvirt already is allowed to create sockets anywhere). >> > > > > >=20 >> > > > > > There are plenty of other places where we allow arbitrary path= s in the >> > > > > > XML, but which have restrictions imposed by the security drive= rs. Not >> > > > > > least the 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. >> > > > > >=20 >> > > > > > I don't think we want to grant QEMU svirtt permission to creat= e 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 = for 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= admin >> > > > > intervention (e.g. to label the whole tree for a non-standard lo= cation). >> > > >=20 >> > > > Does OVS has some limit for it's sockets to be only in >> > > > /var/run/openvswitch ? >> >=20 >> > 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. >>=20 >> Just a question about the usage of openvswitch, in this user case when >> launching a vhostuser/dpdk via libvirt, qemu works as server mode for so= cket >> under /var/run/openvswitch, but per my previous test, ovs/dpdk always wo= rks >> as server mode, which means ovs will creates the socket and listening for >> connection, thus qemu works as client mode, does ovs/dpdk support workin= g in >> client mode? which means it's qemu's duty to create the socket? and ovs = will >> connect to it on demanding? > > Oh, I was assuming that QEMU would be working in server mode - no wonder > we have somewhat different views :-) > > If OVS is running the UNIX socket server, and QEMU is purely the client, > then that means the solution would be slightly different. In particular > 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 connect > to the SELinux type associated with the openvswitch socket. I agree, this is a good MAC solution. > 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 reduces pollution into other aspects of each process' function. -Aaron > > Regards, > Daniel