qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P . Berrangé
Subject: Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
Date: Thu, 16 Jul 2020 09:36:54 +0100
User-agent: Mutt/1.14.5 (2020-06-23)

On Thu, Jul 16, 2020 at 08:55:43AM +0200, Cornelia Huck wrote:
> On Tue, 14 Jul 2020 18:40:11 +0530 (IST)
> P J P <ppandit@redhat.com> wrote:
> 
> <just commenting on this one>
> 
> >  * QEMU would abort(3), if a user attempts to start QEMU with insecure 
> > options 
> >    like say -virtfs OR -fda fat:floopy OR -netdev user OR -device tulip ?  
> > 
> >  * One way could be to abort(3) at options parsing stage, if 'security' 
> > flag 
> >    is set to high(1) and continue further if it is low(0).
> 
> 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.) 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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]