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

[Daniel P . Berrangé]

On Tue, Jul 14, 2020 at 03:48:56PM +0200, Kevin Wolf wrote:
> Am 14.07.2020 um 15:30 hat Daniel P. Berrangé geschrieben:
> > On Tue, Jul 14, 2020 at 07:02:59AM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Jul 14, 2020 at 11:22:28AM +0100, Peter Maydell wrote:
> > > > On Tue, 14 Jul 2020 at 11:12, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > And for people who want to build QEMU with lots of functionality (like
> > > > > Fedora does), I think a -security flag would be a useful addition.
> > > > > We can then tell security researchers "only a high security issue
> > > > > if it reproduces with -security=high, only a security issue
> > > > > if it reproduces with -security=low".
> > > > 
> > > > I think a -security option would also be useful to users -- it
> > > > makes it easier for them to check "is this configuration using
> > > > something that I didn't realize was not intended to be secure".
> > > > For me, something useful for our users is much more compelling
> > > > than "this might make security researchers' lives a bit easier".
> > > > 
> > > > thanks
> > > > -- PMM
> > > 
> > > True. And I guess downstreams can also force the option to high or set the
> > > default to high rather easily if they want to.
> > > 
> > > So the option would be:
> > > 
> > > -security level
> > >   Set minimal required security level of QEMU.
> > > 
> > >   high: block use of QEMU functionality which is intended to be secure 
> > > against
> > >           malicious guests.
> > >   low: allow use of all QEMU functionality, best effort security
> > >           against malicious guests.
> > > 
> > > Default would be -security low.
> > > 
> > > Does this look reasonable?
> > 
> > The challenge I see is that wiring up a runtime flag into every relevant
> > part of the QEMU codebase is an pretty large amount of work. Every device,
> > every machine type, every backend type, every generic subsystem will all
> > need checks for this flag. It is possible, but it isn't going to be quick
> > or easy, especially with poor error reporting support in many areas.
> 
> Would it make more sense as a configure flag that decides whether or not
> to compile in potentially problematic devices/backends?

In the perfect world I think we need both because they satisfy different
scenarios.

There are people who are so paranoid they don't want the insecure code
compiled at all. They want a binary guaranteed to only have the trustworthy
code.

Then there are the people who just want protection against making silly
mistakes in their configuration, but want to be able choose between the
features at runtime.

For security researchers reporting issues, I think we already do enough
by documenting what we consider in / out of scope.  In most cases we
can quickly identify whether the reported flaw is in or out of scope.
So I wouldn't think too much about what to do for security researchers.

It is more productive to focus on what our real users needs.

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