qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: P J P <ppandit@redhat.com>
To: "Michael S . Tsirkin" <mst@redhat.com>,
	"Daniel P . Berrange" <berrange@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Prasad J Pandit <pjp@fedoraproject.org>,
	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: [PATCH 0/1] MAINTAINERS: add security quotient field
Date: Tue, 14 Jul 2020 14:06:30 +0530	[thread overview]
Message-ID: <20200714083631.888605-1-ppandit@redhat.com> (raw)

From: Prasad J Pandit <pjp@fedoraproject.org>

Hello,

QEMU supports numerous virtualisation and emulation use cases.
It 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.

Recently we received multiple security issue reports against VVFAT
and VirtFS host directory sharing system. After discussing with the
respective maintainers, it turned out that

* VVFAT -> https://bugs.launchpad.net/qemu/+bug/1883083
  VVFAT is quite old and is available for testing purposes only.
  Ie. It is not suitable for production environments.

* VirtFS/9pfs -> https://wiki.qemu.org/Documentation/9psetup
  VirtFS implementation though better, it is most commonly used for
  automated testing under sand-boxed server environments, ie. no
  malicious party there. It is also not mature enough for cloud services.
  It is supported on 'Odd Fixes' basis atm.

So these turned out to be issues which can be fixed as regular bugs.

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.

This patch introduces the CVE (or Security or Trust) Quotient field
in the MAINTAINERS file. It tries to capture the security sensitivity
pertaining to a feature or section of the QEMU's code base.

It indicates whether a potential issue should be treated as a security
one OR it could be fixed as a regular non-security bug.

    If Quotient == High, triage issues as potential security ones.
    if Quotient == Low,  triage issues as regular non-security bugs.

I have tagged each section in the MAINTAINERS file as High or Low on best
guess basis. I request respective maintainers to kindly review it please.

If you have any inputs/suggestions, I'd really appreciate them.

Thank you.
--
Prasad J Pandit (1):
  MAINTAINERS: introduce cve or security quotient field

 MAINTAINERS | 324 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 324 insertions(+)

--
2.26.2



             reply	other threads:[~2020-07-14  8:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14  8:36 P J P [this message]
2020-07-14  8:36 ` [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field 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
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=20200714083631.888605-1-ppandit@redhat.com \
    --to=ppandit@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=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).