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: P J P
Subject: Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
Date: Thu, 16 Jul 2020 15:14:51 +0530 (IST)

+-- On Thu, 16 Jul 2020, Dr. David Alan Gilbert wrote --+
| > +   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;
| ....

  Yes, I started with the MAINTAINERS file thinking at least some segregation 
would be a step forward than nothing.
 
| >  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;

   No, High OR Low was not for excluding it from any build. It was merely an 
indication to a user to decide whether an issue should be treated as a CVE one 
or can be fixed as regular bug.

| but QMP is expected to be talking to another trusted endpoint.

  True; I set it to Low as QMP interface access is mostly given to privileged 
trusted users.


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D




reply via email to

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