From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8Qxr-0004hk-5u for qemu-devel@nongnu.org; Thu, 02 Jun 2016 07:39:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8Qxl-0000bm-ET for qemu-devel@nongnu.org; Thu, 02 Jun 2016 07:39:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8Qxl-0000bZ-69 for qemu-devel@nongnu.org; Thu, 02 Jun 2016 07:38:57 -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 45ADD62672 for ; Thu, 2 Jun 2016 11:38:56 +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> From: Michal Privoznik Message-ID: <297e40a1-9df0-cd85-68a1-b4ef5479f8bf@redhat.com> Date: Thu, 2 Jun 2016 13:38:53 +0200 MIME-Version: 1.0 In-Reply-To: <20160602082904.GD9481@redhat.com> 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 , jasowang@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, amit.shah@redhat.com 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 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. >>> >>> 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 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 th= is >> 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 qem= u >> 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). >=20 > 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 directo= ry > for the sockets. We certainly do not want to allow QEMU to create socke= ts > anywhere. >=20 > 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 vhos= t > 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