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

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

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.

Best regards,
Christian Schoenebeck