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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28FF1C433F5 for ; Thu, 30 Sep 2021 10:33:04 +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 8378661882 for ; Thu, 30 Sep 2021 10:33:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8378661882 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:34688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVtN8-0003YN-Mj for qemu-devel@archiver.kernel.org; Thu, 30 Sep 2021 06:33:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46982) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVtLG-0001y9-3M for qemu-devel@nongnu.org; Thu, 30 Sep 2021 06:31:07 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:54431) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVtLA-0006BE-FY for qemu-devel@nongnu.org; Thu, 30 Sep 2021 06:31:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632997858; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1LdDo/aO4T4/u7SlfRZRwccYmDGejjKHpxqBAJClDwA=; b=R5sMYlM4i7Y59faFXUpdfHohR3KcOUTSt8EeUZy8b78lNODq3SHAOFT+EXGgrGByVAj8+G WOVsXfFDvcwVqogpnMvQPyhePeZ21gxC+WwJmBE8v1ajd6x9rBQFzvzbyWM3cTB2oQqpni 9uDr2ERMct8o8tF/a7cCIddoe6l9wCk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-201-OXBYxjN3NhejJMUuaXLn1w-1; Thu, 30 Sep 2021 06:30:51 -0400 X-MC-Unique: OXBYxjN3NhejJMUuaXLn1w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 738C01006AA4; Thu, 30 Sep 2021 10:30:49 +0000 (UTC) Received: from redhat.com (unknown [10.39.195.104]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 715E760BD8; Thu, 30 Sep 2021 10:30:30 +0000 (UTC) Date: Thu, 30 Sep 2021 11:30:27 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: P J P Subject: Re: [RFC PATCH 00/10] security: Introduce qemu_security_policy_taint() API Message-ID: References: <20210908232024.2399215-1-philmd@redhat.com> <798304472.4432617.1631626227208@mail.yahoo.com> MIME-Version: 1.0 In-Reply-To: <798304472.4432617.1631626227208@mail.yahoo.com> User-Agent: Mutt/2.0.7 (2021-05-04) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=216.205.24.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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: Peter Maydell , Thomas Huth , Eduardo Habkost , "qemu-block@nongnu.org" , "Michael S. Tsirkin" , Eric Blake , Richard Henderson , Markus Armbruster , "qemu-devel@nongnu.org" , "xen-devel@lists.xenproject.org" , Paolo Bonzini , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, Sep 14, 2021 at 01:30:27PM +0000, P J P wrote: > Hello Philippe, all > > >On Thursday, 9 September, 2021, 03:58:40 pm IST, Daniel P. Berrangé wrote: > >On Thu, Sep 09, 2021 at 01:20:14AM +0200, Philippe Mathieu-Daudé wrote: > >> This series is experimental! The goal is to better limit the > >> boundary of what code is considerated security critical, and > >> what is less critical (but still important!). > >> > >> This approach was quickly discussed few months ago with Markus > >> then Daniel. Instead of classifying the code on a file path > >> basis (see [1]), we insert (runtime) hints into the code > >> (which survive code movement). Offending unsafe code can > >> taint the global security policy. By default this policy > >> is 'none': the current behavior. It can be changed on the > >> command line to 'warn' to display warnings, and to 'strict' > >> to prohibit QEMU running with a tainted policy. > > > > * Thanks so much for restarting this thread. I've been at it intermittently last few >   months, thinking about how could we annotate the source/module objects. > >    -> [*] https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg04642.html > > * Last time we discussed about having both compile and run time options for users >   to be able to select the qualified objects/backends/devices as desired. Right, we have multiple different use cases here - People building QEMU who want to cut down what they ship to minimize the stuff they support, which is outside the security guarantee. This can be OS distros, but also any other consumer of QEMU eg. RHEL wants to cut out almost all non-virtualization stuff. There is a quirk here though, that RHEL still includes TCG which is considered outside the security guarantee. So a simple build time "--secure on|off" doesn't do the job on its own. We need something to let people understand the consequences of the build options they are enabling. NB, when I talk of build options, I include both configure/meson args, and also the CONFIG_* options set in configs/**/*.mak - Application developers want to check that they're not using stuff outside the security guarantee, even if the distro has enable it. These need to be able to query whether the VM they've launched has undesirable configuration choices. Some people fall into both groups, some people fall into neither group. > * To confirm: How/Where is the security policy defined? Is it > device/module specific OR QEMU project wide? Currently our only definition is in the docs https://qemu-project.gitlab.io/qemu/system/security.html#security-requirements Philippe's patch is proposing tagging against internal QEMU objects of various types. I further proposed that we expose this in QMP so it is introspectable. I think there's scope for doing stuff at build time with configure args and *mak CONFIG_* options, but haven't thought what that might look like. > > IOW, the reporting via QAPI introspetion is much more important > > for libvirt and mgmt apps, than any custom cli arg / printfs > > at the QEMU level. > > > > * True, while it makes sense to have a solution that is conversant with >   the management/libvirt layers, It'll be great if we could address qemu/cli >   other use cases too. > > >it feels like we need > >  'secure': 'bool' > > * Though we started the (above [*]) discussion with '--security' option in mind, >   I wonder if 'secure' annotation is much specific. And if we could widen its scope. > --- x --- > > > Source annotations: I've been thinking over following approaches > =================== > > 1) Segregate the QEMU sources under > >       ../staging/      <= devel/experimental, not for production usage >       ../src/          <= good for production usage, hence security relevant >       ../deprecated/   <= Bad for production usage, not security relevant  > >    - This is similar to Linux staging drivers' tree. >    - Staging drivers are not considered for production usage and hence CVE allocation. >    - At build time by default we only build sources under ../src/ tree. >    - But we can still have options to build /staging/ and /deprecated/ trees.   >    - It's readily understandable to end users. I don't think we should be working in terms of source files at all. Some files contain multiple distinct bits of functionality that are not easily separated, and will have distinct security levels. Also IMHO it is unpleasant to be moving files around in git to when code switches between levels. Also there are distinct criteria here, both security levels, and support levels - there can be stuff which is fully supported but considered insecure, and stuff that is deprecated but considered secure. > 2) pkgconfig(1) way: >    - If we could define per device/backend a configuration (.pc) file which is then used >      at build/run time to decide which sources are suitable for the build or usage. > >    - I'm trying to experiment with this. For build time configuration, we have a pretty clear set of toggles between the configure/meson options, and the CONFIG_* make options. I don't think we need to complicate things by trying to add pkg-config into the mix here. > 3) We annotate QEMU devices/backends/modules with macros which define its status. >    It can then be used at build/run times to decide if it's suitable for usage. What is what Philippe's patches are doing in essence Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|