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

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Donnerstag, 16. Juli 2020 12:01:57 CEST Daniel P. Berrangé wrote:
> > My concern here is that just distinguishing between either 'low' or 'high'
> > is a far too rough classification.
> > 
> > In our preceding communication regarding 9pfs, I made clear that a) we do
> > care about security relevant 9pfs issues, and only b) the avarage use
> > cases (as far we know) for 9pfs are above a certain trust level.
> > 
> > However b) does not imply 9pfs being 'unsafe', nor that we want users to
> > refrain using it in a security relevant environment. So 9pfs would
> > actually be somewhere in between.
> 
> We shouldn't overthink this and invent many classification levels.
> 
> This is essentially about distinguishing code that is written with the
> intent of protecting from a malicous guest, from code that assumes a
> non-malicious guest. That is a pretty clear demarcation on when it is
> reasonable to use any given feature in QEMU.
> 
> Within the set of code that is assuming a malicious guest, there are
> still going to be varying levels of quality, and that is ok. We don't
> need to express that programatically, the docs are still there to
> describe the fine nuances of any given feature. We're just saying that
> in general, this set of code is acceptable to use in combination with
> a malicious guest, and if you find bugs we'll triage them as security
> flaws.

Yes, that would be a base consideration for any security classification. And 
it applies to 9pfs hence it would suggest 'high' for 9pfs, but ...

> 9p is generally written from the POV of protecting against a malicious
> guest, so it would be considered part of the high security set, and
> flaws will be treated as CVEs. We don't need to be break it down into
> any more detail than that.

... this is where it already differs from reality, as 9pfs security issues 
were both handled as CVEs as well as normal reports for years, which nobody 
objected.

So I wonder how helpful it would be trying to either put 9pfs into either 
'high' or 'low', because another observed problematic with 9pfs is that the 
degree of participation is so low, that if you try to impose certain formal 
minimum requirements to contributors, you usually never hear from them again.

And BTW Prasad actually suggested the opposite classification: 

> @@ -1761,6 +1927,7 @@ virtio-9p
> 
>  M: Greg Kurz <groug@kaod.org>
>  M: Christian Schoenebeck <qemu_oss@crudebyte.com>
>  S: Odd Fixes
> 
> +C: Low
> 
>  F: hw/9pfs/
>  X: hw/9pfs/xen-9p*
>  F: fsdev/

Even though we discussed this issue with him in detail before, which probably 
shows that a simple binary security classification is too coarse and too 
ambiguous.

Best regards,
Christian Schoenebeck