From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCnko-0005Q0-Tw for qemu-devel@nongnu.org; Tue, 14 Jun 2016 08:47:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCnkj-0002L1-Tj for qemu-devel@nongnu.org; Tue, 14 Jun 2016 08:47:37 -0400 Received: from mx3-phx2.redhat.com ([209.132.183.24]:49800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCnkj-0002Kp-Lk for qemu-devel@nongnu.org; Tue, 14 Jun 2016 08:47:33 -0400 Date: Tue, 14 Jun 2016 08:47:31 -0400 (EDT) From: Amnon Ilan Message-ID: <1543701363.59905886.1465908451809.JavaMail.zimbra@redhat.com> In-Reply-To: <575FBA5F.50201@redhat.com> References: <1464712247-11655-1-git-send-email-wexu@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> 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: Wei Xu Cc: Aaron Conole , Flavio Leitner , Michal Privoznik , jasowang@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, amit shah ----- Original Message ----- > From: "Wei Xu" > To: "Aaron Conole" , "Flavio Leitner" > Cc: "Michal Privoznik" , jasowang@redhat.com, qemu-d= evel@nongnu.org, armbru@redhat.com, "amit > shah" , "Amnon Ilan" > Sent: Tuesday, June 14, 2016 11:03:43 AM > Subject: Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket 'fd' op= en from outside for unix socket >=20 > 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 > >>>>>>>>> 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 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 > >>>>>> 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 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 > >>>>> 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 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/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. >=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 > 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 working in client mode? which means it's qemu's duty to create > the socket? and ovs will connect to it on demanding? AFAIK qemu supports both client mode and server mode (configurable), so=20 the solution should support both cases. Thanks, Amnon >=20 > > > >>> 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 > > >=20 >=20