From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: P J P <ppandit@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Stefano Stabellini <sstabellini@kernel.org>,
"Daniel P . Berrange" <berrange@redhat.com>,
Prasad J Pandit <pjp@fedoraproject.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
Christian Schoenebeck <qemu_oss@crudebyte.com>,
Michael Roth <mdroth@linux.vnet.ibm.com>,
QEMU Developers <qemu-devel@nongnu.org>,
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: Thu, 16 Jul 2020 09:56:56 +0100 [thread overview]
Message-ID: <20200716085656.GA7813@work-vm> (raw)
In-Reply-To: <20200714083631.888605-2-ppandit@redhat.com>
* 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.
>
> Suggested-by: Daniel P. Berrange <berrange@redhat.com>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> ---
> MAINTAINERS | 324 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 324 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fe8139f367..badf1dab6e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -33,6 +33,14 @@ Descriptions of section entries:
> Obsolete: Old code. Something tagged obsolete generally means
> it has been replaced by a better system and you
> should be using that.
> + 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.
That's a lot of OR's and it causes problems;
....
> QMP
> M: Markus Armbruster <armbru@redhat.com>
> S: Supported
> +C: Low
> F: monitor/monitor-internal.h
> F: monitor/qmp*
> F: monitor/misc.c
QMP is critical to many uses, so you wouldn't want to exclude it from a secure build;
any security issue with it (e.g. misparsing an argument) would be very
serious and would need to be looked at; but QMP is expected to be
talking to another trusted endpoint.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2020-07-16 8:58 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é
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 [this message]
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=20200716085656.GA7813@work-vm \
--to=dgilbert@redhat.com \
--cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.