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

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

On Thu, Jul 16, 2020 at 02:51:55PM +0530, 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.

Yes, I mentioned earlier in the thread that doing this security check at
runtime is going to be a huge amount of work, because it will need to be
wired up across a wide range of subsystems and APIS and implemnetations
in the QEMU codebase.

I don't think option parsing time will be the place you want a check
at all. You need to parse the --security flag, but once that's done
I think everything else needs to be done at time of object creation,
not config parsing. That ensures the check is present in all possible
codepaths that lead to the functionality being used.

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

My suggestion is to do compile time stuff first, as that ought to be a
simpler problem. Having said that, if Paolo's work on meson is likely
to arrive any time soon, then it might make sense to wait for that,
instead of implementing something for Make and then throwing it away
a release later and doing it from scratch in Meson.


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