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

[P J P <ppandit@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

+-- 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.

* If this approach is reasonable, I'll try to make an initial patch towards 
  it.

* We'd still need to figure out similar way for compile time option, to 
  exclude building insecure features at build time.


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