From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 183ACC3A5A2 for ; Fri, 23 Aug 2019 15:07:36 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E22A62166E for ; Fri, 23 Aug 2019 15:07:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E22A62166E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:57632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i1BA6-0003DK-9G for qemu-devel@archiver.kernel.org; Fri, 23 Aug 2019 11:07:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56342) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i1B7u-0000Rg-RE for qemu-devel@nongnu.org; Fri, 23 Aug 2019 11:05:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i1B7t-0006gv-4g for qemu-devel@nongnu.org; Fri, 23 Aug 2019 11:05:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57167) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i1B7s-0006gQ-Sh for qemu-devel@nongnu.org; Fri, 23 Aug 2019 11:05:17 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3A7597F758; Fri, 23 Aug 2019 15:05:16 +0000 (UTC) Received: from redhat.com (ovpn-112-60.ams2.redhat.com [10.36.112.60]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 237FE60925; Fri, 23 Aug 2019 15:05:10 +0000 (UTC) Date: Fri, 23 Aug 2019 16:05:08 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: "Dr. David Alan Gilbert" Message-ID: <20190823150508.GM9654@redhat.com> References: <20190823112053.GE9654@redhat.com> <20190823114157.GG9654@redhat.com> <20190823130014.GG2784@work-vm> <20190823140948.GI2784@work-vm> <20190823142054.GK9654@redhat.com> <20190823142602.GJ2784@work-vm> <20190823144052.GL9654@redhat.com> <20190823145634.GK2784@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190823145634.GK2784@work-vm> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.71]); Fri, 23 Aug 2019 15:05:16 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Laurent Vivier , Thomas Huth , Juan Quintela , qemu-devel , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Stefan Hajnoczi , Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Fri, Aug 23, 2019 at 03:56:34PM +0100, Dr. David Alan Gilbert wrote: > * Daniel P. Berrang=C3=A9 (berrange@redhat.com) wrote: > > On Fri, Aug 23, 2019 at 03:26:02PM +0100, Dr. David Alan Gilbert wrot= e: > > > * Daniel P. Berrang=C3=A9 (berrange@redhat.com) wrote: > > > > On Fri, Aug 23, 2019 at 03:09:48PM +0100, Dr. David Alan Gilbert = wrote: > > > > > * Marc-Andr=C3=A9 Lureau (marcandre.lureau@gmail.com) wrote: > > > > > > Hi > > > > > >=20 > > > > > > On Fri, Aug 23, 2019 at 5:00 PM Dr. David Alan Gilbert > > > > > > wrote: > > > > > > > > > > > > > > * Daniel P. Berrang=C3=A9 (berrange@redhat.com) wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This means QEMU still has to iterate over every single cl= ient > > > > > > > > on the bus to identify them. If you're doing that, there'= s > > > > > > > > no point in owning a well known service at all. Just iter= ate > > > > > > > > over the unique bus names and look for the exported objec= t > > > > > > > > path /org/qemu/VMState > > > > > > > > > > > > > > > > > > > > > > Not knowing anything about DBus security, I want to ask how= do > > > > > > > we handle security here? > > > > > >=20 > > > > > > First of all, we are talking about cooperative processes, and= having a > > > > > > specific bus for each qemu instance. So some amount of securi= ty/trust > > > > > > is already assumed. > > > > >=20 > > > > > Some but we need to keep it as limited as possible; for example= two > > > > > reasons for having separate processes both come down to securit= y: > > > > >=20 > > > > > a) vtpm - however screwy the qemu is, you can never get to th= e keys in > > > > > the vtpm > > > >=20 > > > > Processes connected to dbus can only call the DBus APIs that vtpm > > > > actually exports. The vtpm should simply *not* export a DBus > > > > API that allows anything to fetch the keys. > > > >=20 > > > > If it did want to export APIs for fetching keys, then we would > > > > have to ensure suitable dbus /selinux policy was created to > > > > prevent unwarranted access. > > >=20 > > > This was really just one example of where the security/trust isn't > > > assumed; however a more concrete case is migration of a vtpm, and e= ven > > > though it's probably encrypted blob you still don't want some other > > > device to grab the migration data - or to say reinitialise the vtpm= . > >=20 > > That can be dealt with by the dbus security policies, provided > > you either run the vtpm as a different user ID from the other > > untrustworthy helpers, or use a different selinux context for > > vtpm. You can then express that only the user that QEMU is > > running under can talk to vtpm over dbus. >=20 > The need for the extra user ID or selinux context is a pain; > but probably warranted for the vTPM; in general though some of this > exists because of the choice of DBus and wouldn't be a problem for > something that had a point-to-point socket it sent everything over. NB be careful to use s/DBus/DBus bus/ DBus the protocol is fine to be used in a point-to-point socket scenario - the use of the bus is strictly optional. If all communication we expect is exclusively Helper <-> QEMU, then I'd argue in favour of dbus in point-to-point mode. The use cases Stefan brought up for virtiofsd though is what I think brings the idea of using the bus relevant. It is the desire to allow online control/mgmt of the helper, which introduces a 3rd party which isn't QEMU. Instead either libvirt or a standalone admin/debugging tool. With multiple parties involved I think the bus becomes relevant With p2p mode you could have 2 dbus socket for Helper <-> QEMU and another dbus socket for Helper <-> libvirt/debugging, but this isn't an obvious security win over using the bus, as you now need different access rules for each of the p2p sockets to say who can connect to which socket.=20 > > Where I think you could have problems is if you needed finer > > grainer control with selinux. eg if vstpm exports 2 different > > services, you can't allow access to one service, but forbid > > access to the other service. > >=20 > > > > > b) virtio-gpu, loads of complex GPU code that can't break the= main > > > > > qemu process. > > > >=20 > > > > That's no problem - virtio-gpu crashes, it disappears from the db= us > > > > bus, but everything else keeps running. > > >=20 > > > Crashing is the easy case; assume it's malicious and you don't want= it > > > getting to say a storage device provided by another vhost-user devi= ce. > >=20 > > If we assume that the 2 processes can't commnuicate / access each > > other outside DBus, then the attack avenues added by use of dbus > > are most likely either: > >=20 > > - invoking some DBus method that should not be allowed due > > to incomplete dbus security policy.=20 > >=20 > > - finding a crash in a dbus client library that you can somehow > > exploit to get remote code execution in the separate process > >=20 > > I won't claim this is impossible, but I think it helps to be > > using a standard, widely used battle tested RPC impl, rather > > than a home grown RPC protocol. >=20 > It's only the policy case I worry about; and my point here is if we > decide to use dbus then we have to think properly about security and > defined stuff. >=20 > >=20 > >=20 > > > > > > But if necessary, dbus can enforce policies on who is allowed= to own a > > > > > > name, or to send/receive message from. As far as I know, this= is > > > > > > mostly user/group policies. > > > > > >=20 > > > > > > But there is also SELinux checks to send_msg and acquire_svc = (see > > > > > > dbus-daemon(1)) > > > > >=20 > > > > > But how does something like SELinux interact with a private dbu= s=20 > > > > > rather than the system dbus? > > > >=20 > > > > There's already two dbus-daemon's on each host - the system one a= nd > > > > the session one, and they get different selinux contexts, > > > > system_dbus_t and unconfined_dbus_t. > > > >=20 > > > > Since libvirt would be responsible for launching these private db= us > > > > daemons it would be easy to make it run svirt_dbus_t for example= . > > > > Actually it would be svirt_dbus_t:s0:cNNN,cMMM to get uniqueness > > > > per VM. > > > >=20 > > > > Will of course require us to talk to the SELinux maintainers to > > > > get some sensible policy rules created. > > >=20 > > > This all relies on SELinux and running privileged qemu/vhost-user p= airs; > > > needing to do that purely to enforce security seems wrong. > >=20 > > Compare to an alternative bus-less solution where each helper has > > a direct UNIX socket connection to QEMU. > >=20 > > If two helpers are running as the same user ID, then can still > > directly attack each other via things like ptrace or /proc/$PID/mem, > > unless you've used SELinux to isolate them, or run each as a distinct > > user ID. If you do the latter, then we can still easily isolate > > them using dbus. >=20 > You can lock those down pretty easily though. How were you thinking ? If you're not using SELinux or separate user IDs, then AFAICT you've got a choice of using seccomp or containers. seccomp is really hard to get a useful policy out of with QEMU, and using containers for each helper process adds a level of complexity worse than selinux or separate user IDs, so isn't an obvious win over using dbus. Regards, Daniel --=20 |: https://berrange.com -o- https://www.flickr.com/photos/dberran= ge :| |: https://libvirt.org -o- https://fstop138.berrange.c= om :| |: https://entangle-photo.org -o- https://www.instagram.com/dberran= ge :|