From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8X1T-0007u5-2q for qemu-devel@nongnu.org; Thu, 02 Jun 2016 14:07:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8X1N-0007JZ-Ue for qemu-devel@nongnu.org; Thu, 02 Jun 2016 14:07:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8X1N-0007JV-MJ for qemu-devel@nongnu.org; Thu, 02 Jun 2016 14:07:05 -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 1C06F63146 for ; Thu, 2 Jun 2016 18:07:05 +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> From: Wei Xu Message-ID: <575075C4.2030202@redhat.com> Date: Fri, 3 Jun 2016 02:07:00 +0800 MIME-Version: 1.0 In-Reply-To: <297e40a1-9df0-cd85-68a1-b4ef5479f8bf@redhat.com> 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: Michal Privoznik , "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, amit.shah@redhat.com, jasowang@redhat.com, armbru@redhat.com On 2016=E5=B9=B406=E6=9C=8802=E6=97=A5 19:38, Michal Privoznik wrote: > 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 wro= te: >>>>> 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 qemu t= o >>>>>> 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 mere= ly >>>>>> 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 soc= ket >>>>> - not >>>>> least because that is exactly what QEMU uses for its QMP monitor ba= ckend. >>>>> Looking at your example command line, I think the issue is simply t= hat >>>>> 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 a= s a >>>> network interface for a vm, similar as the qcow image file, thus sho= uld >>>> 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 create a >>> vhostuser interface and even specify where the socket should be place= d: >>> >>> >>> >>> >>> >>> >>> >>> 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,bu= s=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 t= his >>> and have users manually label the dir (unless already labeled). 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 qe= mu >>> create sockets just anywhere in the system. This, however, brings hug= e >>> 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 (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 as this >> network device, and require use of /var/lib/libvirt/qemu as the direct= ory >> for the sockets. We certainly do not want to allow QEMU to create sock= ets >> anywhere. AFAIK, Vhost user is an interface for third party implementations, and=20 ovs/dpdk is one of the most popular choices, if it limits the socket=20 location of a fixed and unprivileged directory to qemu, actually this=20 should be the default and only one option, this maybe also a security=20 consideration, so we'll have no other choice but ask sys admin to=20 manipulate the permission, looks accepting a safe passed in 'fd' from=20 libvirt is more rigorous and convenient, i'm not sure if this is a=20 typical or a corner scenario. Daniel, How do you think about this with a general purpose? does qemu need such=20 a feature? >> >> I don't think we want to grant QEMU svirtt permission to create socket= s >> in the /var/run/openvswitch directory either really.IMHO, users of vho= st >> user should really be using /var/lib/libvirt/qemu, as is used for all >> 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 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 location)= . > > Michal >