Re: [Qemu-devel] [RFC PATCH-for-4.2] tracing: Allow to tune tracing options via the environment

[Daniel P . Berrangé]

On Mon, Jul 08, 2019 at 12:27:12PM +0200, Philippe Mathieu-Daudé wrote:
> On 7/8/19 11:34 AM, Daniel P. Berrangé wrote:
> > On Sat, Jul 06, 2019 at 06:02:18AM +0200, Markus Armbruster wrote:
> >> Philippe Mathieu-Daudé <address@hidden> writes:
> >>
> >>> On 7/5/19 3:19 PM, Markus Armbruster wrote:
> >>>> Philippe Mathieu-Daudé <address@hidden> writes:
> >>>>> On 7/5/19 10:07 AM, Stefan Hajnoczi wrote:
> >>>>>> On Thu, Jul 04, 2019 at 11:28:37AM +0100, Daniel P. Berrangé wrote:
> >>>>>>> On Thu, Jul 04, 2019 at 11:24:57AM +0100, Stefan Hajnoczi wrote:
> >> [...]
> >>>>>>>> What is the concern about adding these environment variables to QEMU?
> >>>>>>>>
> >>>>>>>> It is convenient to be able to use tracing even if QEMU is invoked by
> >>>>>>>> something you cannot modify/control.
> >>>>>>>>
> >>>>>>>> The main issues I see with environment variables are:
> >>>>>>>>
> >>>>>>>> 1. Security.  Is there a scenario where an attacker can use 
> >>>>>>>> environment
> >>>>>>>>    variables to influence the behavior of a QEMU process running at a
> >>>>>>>>    different trust level?
> >>>>
> >>>> The common (and sad) solution for this is to require whatever runs $PROG
> >>>> at a different trust level to scrub the environment.
> >>>
> >>> I hope people concerned by security build QEMU with the NOP trace backend.
> >>
> >> I sure hope at least one of our tracing backends (other than nop) can be
> >> used safely in production.
> 
> I'm not saying production and security are orthogonal, but recent trend
> in security seems to reduce code exposure by disabling component, so I'd
> not be surprise if people who primary concern is strong security to use
> the NOP trace backend as default.
> 
> > AFAIK, *all* of the trace backends are safe for use in production. The
> > only questions are around performance in production.  If anyone knows of
> > any security problems with specific backends we should either address them,
> > or document the backend is unsafe.
> 
> I hope the tracing backend/frontends are safe. Now the trace events log
> a bunch of interesting information, so I'd not be surprise if some
> security researcher open a "QEMU information leak" CVE because we log
> various guest pointers i.e.

There would only be an information leak if the information was made
available to users/apps which are running at a lower privilege level
than QEMU. If you are root, or running as the QEMU user/group, then
all the information is already available by ptrace'ing QEMU or other
means. The tracing framework merely makes it available in an easier
to access way.

> Anyway, to stop bikeshedding this thread, can you add few lines about
> why not use getenv() in the HACKING?

I don't actually think the getenv thing is a security issue in any case.
If there was a security problem exploitable via getenv, then the bug would
lie in the application invoking QEMU for not ensuring the ENV contents
were safe before exec'ing QEMU. Libvirt is paranoid by default and scrubs
QEMU's env only keeping a specific sanitized whitelist for exactly these
reasons.

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