qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field


From: Dr. David Alan Gilbert
Subject: Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
Date: Thu, 16 Jul 2020 09:56:56 +0100
User-agent: Mutt/1.14.5 (2020-06-23)

* 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]