From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8O08-0001rM-78 for qemu-devel@nongnu.org; Thu, 02 Jun 2016 04:29:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8O04-0003oJ-VR for qemu-devel@nongnu.org; Thu, 02 Jun 2016 04:29:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8O04-0003oF-NL for qemu-devel@nongnu.org; Thu, 02 Jun 2016 04:29:08 -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 3557D85364 for ; Thu, 2 Jun 2016 08:29:08 +0000 (UTC) Date: Thu, 2 Jun 2016 09:29:04 +0100 From: "Daniel P. Berrange" Message-ID: <20160602082904.GD9481@redhat.com> Reply-To: "Daniel P. Berrange" 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <01045d4a-f03d-9f0d-deeb-4927446bb894@redhat.com> 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 Cc: Wei Xu , jasowang@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, amit.shah@redhat.com 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 wrot= e: > >> 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 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 merel= y > >>> 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 sock= et > >> - not > >> least because that is exactly what QEMU uses for its QMP monitor bac= kend. > >> Looking at your example command line, I think the issue is simply th= at > >> 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 shou= ld > > 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=3D= pci.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 thi= s > 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 i= s > 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 (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 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 for all other UNIX sockets we create wrt other devices. > >> Alternatively you could enhance the SELinux policy to grant svirt_t = the > >> permission to create sockets under /var/run/openvswitch too. >=20 > Nah, the point of using libvirt is that you don't have to configure > anything (or just bare minimum) and libvirt makes sure your domains hav= e > all the permissions needed - that's why we relabel domain's disks when > starting it up. That's semi-true - we don't actually support arbitrary locations for disks - there are plenty of locations that will not work, even if libvirt labels the disk file, due to restrictions accessing the parent directories by SELinux. Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|