Re: Making QEMU easier for management tools and applications

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

On Thu, Jan 23, 2020 at 01:13:33PM -0500, John Snow wrote:
> 
> 
> On 1/23/20 5:27 AM, Daniel P. Berrangé wrote:
> > On Wed, Jan 22, 2020 at 05:42:10PM -0500, John Snow wrote:
> >>
> >>
> >> On 12/24/19 8:00 AM, Daniel P. Berrangé wrote:
> >>> Based on experiance in libvirt, this is an even larger job than (4),
> >>> as the feature set here is huge.  Much of it directly ties into the
> >>> config problem, as to deal with SELinux / namespace setup the code
> >>> needs to understand what resources to provide access to. This
> >>> requires a way to express 100% coverage of all QEMU configuration
> >>> in use & analyse it to determine what resources it implies. So this
> >>> ties strongly into QAPI-ification completion.
> >>
> >> Is it totally bonkers to suggest that QEMU provide a method of digesting
> >> a given configuration and returning a configuration object that a
> >> standalone jailer can use?
> >>
> >> So we have a QEMU manager, the generic jailer, and QEMU. QEMU and the
> >> manager cooperate to produce the jailing configuration, and the jailer
> >> does what we ask it to.
> > 
> > It isn't clear what you mean by "QEMU" here. If this QEMU, the system
> > emulator process, then this is the untrustworthy part of the stack,
> > so the jailer must not use any data that QEMU is providing. In fact
> > during startup the jailer does its work before QEMU even exists.
> > 
> 
> I worried about this. Hence the "Nuts?" ask. It sounds like the ultimate
> problem is nobody can know -- except QEMU -- what permissions are truly
> needed for a given configuration. Even if we had an immaculate API, how
> would anyone except QEMU developers know?
> 
> Trial and error, perhaps, on behalf of the jailer developers. Trial and
> error is not the greatest feature of a security mechanism. Clearly, a
> lot of effort has been spent to get libvirt's implementation correct,
> but Stefan raises the idea that other projects have need of
> understanding how to map QEMU configurations to appropriate jails.
> 
> Worse, it could still change on a whim. We (QEMU developers) probably
> are not used to thinking of permitted syscall lists as ABI that we
> strive to maintain. It can change.
> 
> How do we make this easier in a way that doesn't trust QEMU? I feel like
> QEMU needs to provide *some* kind of information that can be used to
> build better jailing configurations...

I think the key thing to understand is that once you involve a "jailer"
then "QEMU" is no longer a single thing we can refer to. It is immediately
split into two pieces, "the launcher" and "the runtime", with a jailer
sitting in between the pair.

The configuration information needed by the launcher is a superset
of the information needed by the runtime. The launcher is trustworthy
and the runtime is untrustworthy.

In the current world qemu-system-* is the runtime and libvirt is
the launcher, and they each have their own completely different
vocabulary for configuration.

Essentially what you're talking about is a way to bring the concept
of the launcher under the responsibility of the QEMU project, and
have much closer alignment between the configuration for the launcher
and the runtime. One would still need to be the superset of the
other, but they could be 90% common. 

Having "the launcher" be part of the QEMU project deliverables is
a completely reasonable concept. Libvirt only took on that role
itself because QEMU has never provided any solution for this
problem itself.  I don't think this is a technically difficult
task. The issues are simply around the practicality of the size/
scope of the work required in order to achieve deliver it for the
diverse range of QEMU functionality & use cases.

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