From: "Michael S. Tsirkin" <mst@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>,
Christian Schoenebeck <qemu_oss@crudebyte.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Michael Roth <mdroth@linux.vnet.ibm.com>,
Greg Kurz <groug@kaod.org>, Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 0/1] MAINTAINERS: add security quotient field
Date: Tue, 14 Jul 2020 05:46:06 -0400 [thread overview]
Message-ID: <20200714053258-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20200714083631.888605-1-ppandit@redhat.com>
On Tue, Jul 14, 2020 at 02:06:30PM +0530, P J P wrote:
> 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.
So this attempts to specify a security aspect of specific files.
Which works for some use-cases (e.g. devices) but not others
(common utility functions).
I'd like to propose add a flag that limits QEMU to a secured subset
of functionality at runtime instead.
Then we can just tell security researchers "reproduce this with
-security=high or it's not a security issue".
> --
> Prasad J Pandit (1):
> MAINTAINERS: introduce cve or security quotient field
>
> MAINTAINERS | 324 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 324 insertions(+)
>
> --
> 2.26.2
prev parent reply other threads:[~2020-07-14 9:46 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
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 ` Michael S. Tsirkin [this message]
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=20200714053258-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=berrange@redhat.com \
--cc=groug@kaod.org \
--cc=kwolf@redhat.com \
--cc=mdroth@linux.vnet.ibm.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.