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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jul 16, 2020 at 03:14:51PM +0530, P J P wrote:
> +-- 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.

It needs to consider that the classification will eventually be used to decide
what features are enabled at build time. If QMP is marked as "low" and someone
does a build "only high", then QMP won't get compiled, and thus QEMU will be
useless for mgmt apps.

Also bear in the mind the documented security classification is that approx
anything relevant for use with KVM based deployment is to be considered part
of the trusted code set, and anything that only makes sense for use with TCG
is part of the untrusted code set.

This implies that much general purpose common infrastructure in QEMU is
going to be part of the trusted code set. So that automatically includes
QMP.

NB, the build time classification won't be perfect, but that's largely
because we don't have sufficient granularity in what we build. For
example, although we only care about QMP, IIUC, we can't turn off HMP
at build time.  So we might consider HMP to be "low", despite the fact
that it is impossible to disable when building "only high features".

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|