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

[Daniel P . Berrangé]

On Thu, Jul 16, 2020 at 11:45:50AM +0200, Christian Schoenebeck wrote:
> On Donnerstag, 16. Juli 2020 11:21:55 CEST P J P wrote:
> > +-- On Thu, 16 Jul 2020, Daniel P. Berrangé wrote --+
> > 
> > | > Failing to start (with a message that explains why) if one of the
> > | > command
> > | > line options is not covered by a specified security policy is not
> > | > unreasonable (after all, we fail to start for other cases of
> > | > incompatible
> > | > command line options as well.)
> > 
> >   Yes, that's right.
> > 
> > | > However, we also need to cover dynamically-added devices. Aborting seems
> > | > very bad there, just failing to add the device seems like what we'd
> > | > want.
> > | 
> > | Yep, aborting is simply not an option for the inner code. It all has to
> > | propagate to a proper Error **errp object. The ultimate entry-point at the
> > | CLI vs QMP then decides whether to turn the error into an abort or feed
> > | back to the client app.
> > 
> >   True, handling dynamic devices is tricky.
> > 
> > Though it seems kind of uniform workflow to check for '--security' flag at
> > options parsing OR while handling dynamic devices at run time; It is a huge
> > task to cover all options/use-cases for all QEMU emulators across various
> > architectures.
> 
> 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.

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.

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 :|