qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Prasad J Pandit <pjp@fedoraproject.org>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Christian Schoenebeck <qemu_oss@crudebyte.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	P J P <ppandit@redhat.com>, Greg Kurz <groug@kaod.org>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
Date: Tue, 14 Jul 2020 10:52:33 +0100	[thread overview]
Message-ID: <20200714095233.GC25187@redhat.com> (raw)
In-Reply-To: <CAFEAcA9QWLmi1fGuPW93GXFKV2KCwNs6Xp3U9MU2r4wtendzhg@mail.gmail.com>

On Tue, Jul 14, 2020 at 10:42:55AM +0100, Peter Maydell wrote:
> On Tue, 14 Jul 2020 at 09:40, P J P <ppandit@redhat.com> wrote:
> >
> > From: Prasad J Pandit <pjp@fedoraproject.org>
> >
> > QEMU supports numerous virtualisation and emulation use cases.
> > It also offers many features to support guest's function(s).
> >
> > All of these use cases and features are not always security relevant.
> > Because some maybe used in trusted environments only. Some may still
> > be in experimental stage. While other could be very old and not
> > used or maintained actively.
> >
> > For security bug analysis we generally consider use cases wherein
> > QEMU is used in conjunction with the KVM hypervisor, which enables
> > guest to use hardware processor's virtualisation features.
> >
> > The CVE (or Security or Trust) Quotient field tries to capture this
> > sensitivity pertaining to a feature or section of the code.
> >
> > It indicates whether a potential issue should be treated as a security
> > one OR it could be fixed as a regular non-security bug.
> 
> How does this interact with the way we already document our
> level of security support in docs/system/security.rst ?
> 
> > +       C: CVE/Security/Trust Quotient
> > +          H:High - Feature (or code) is meant to be safe and used by untrusted
> > +                   guests. So any potential security issue must be processed with
> > +                   due care and be considered as a CVE issue.
> > +          L:Low  - Feature (or code) is not meant to be safe OR is experimental
> > +                   OR is used in trusted environments only OR is not well
> > +                   maintained. So any potential security issue can be processed
> > +                   and fixed as regular non-security bug. No need for a CVE.
> 
> The difficulty with this is that MAINTAINERS is not set up
> with a split between "security issues" and "non-security
> issues". For instance this stanza:
> 
> > @@ -149,6 +161,7 @@ ARM TCG CPUs
> >  M: Peter Maydell <peter.maydell@linaro.org>
> >  L: qemu-arm@nongnu.org
> >  S: Maintained
> > +C: Low
> >  F: target/arm/
> >  F: tests/tcg/arm/
> >  F: tests/tcg/aarch64/
> 
> you have marked "Low", but the files it covers include
> both ones used by TCG (not security-critical) and ones
> used by KVM (security-critical).
> 
> Also, MAINTAINERS is not user-facing. If we want to say
> that vvfat or 9pfs are not suitable for use on a security
> boundary and that we do not consider bugs in them to
> be security issues, we should do that in the user-facing
> documentation.
> 
> Broadly speaking, it feels like you're trying to come up
> with an automatic way to say "does this patch touch a
> security-relevant part of the code", and I'm not sure
> that that's possible.

I agree that it isn't possible in the MAINTAINERS file, as the level
of granularity is a very poor match for what we want to express.

My high level thought would be that we should ultimately be able to
have a build flag to request only security-critical code is built
into the binaries.

This is probably a bit too much of a stretch goal right now, but it
at least points towards maintaining the information on a per-file
level of granularity. There might be some individual files which
currently contain a mix security-critical/not-security critical
code. Either they can be split eventually, or we can simply declare
that the entire file is none the less security critical.

We could perhaps have a magic comment at the top of each file that
is security critical. eg

 /* @security: maintained */

we don't need any comment in files we consider non-maintained from
a security POV.  Eventually we could do some (insert hand waving)
magic in meson to pull out this list of comments and use it to
exclude build of files that are not security critical. Maybe we
find out that using a magic comment isn't the best option, but
at least if we start now by keeping a per-file comment, we can
probably do an automated transformation to any other data storage
later.

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 :|



  reply	other threads:[~2020-07-14  9:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14  8:36 [PATCH 0/1] MAINTAINERS: add security quotient field P J P
2020-07-14  8:36 ` [PATCH 1/1] MAINTAINERS: introduce cve or " P J P
2020-07-14  9:42   ` Peter Maydell
2020-07-14  9:52     ` Daniel P. Berrangé [this message]
2020-07-14 10:12       ` Michael S. Tsirkin
2020-07-14 10:22         ` Peter Maydell
2020-07-14 11:02           ` Michael S. Tsirkin
2020-07-14 13:10             ` P J P
2020-07-16  6:55               ` Cornelia Huck
2020-07-16  8:36                 ` Daniel P. Berrangé
2020-07-16  9:21                   ` P J P
2020-07-16  9:39                     ` Daniel P. Berrangé
2020-07-16  9:45                     ` Christian Schoenebeck
2020-07-16 10:01                       ` Daniel P. Berrangé
2020-07-16 12:22                         ` Christian Schoenebeck
2020-07-16 12:54                           ` Daniel P. Berrangé
2020-07-14 13:30             ` Daniel P. Berrangé
2020-07-14 13:48               ` Kevin Wolf
2020-07-14 13:56                 ` Thomas Huth
2020-07-14 15:04                   ` Christian Schoenebeck
2020-07-14 14:02                 ` Daniel P. Berrangé
2020-07-14 10:18   ` Philippe Mathieu-Daudé
2020-07-14 11:51   ` Cornelia Huck
2020-07-16  8:56   ` Dr. David Alan Gilbert
2020-07-16  9:44     ` P J P
2020-07-16 10:09       ` Daniel P. Berrangé
2020-07-16 10:43         ` Markus Armbruster
2020-07-14  9:46 ` [PATCH 0/1] MAINTAINERS: add " Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200714095233.GC25187@redhat.com \
    --to=berrange@redhat.com \
    --cc=groug@kaod.org \
    --cc=kwolf@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=pjp@fedoraproject.org \
    --cc=ppandit@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    --cc=sstabellini@kernel.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).