[libvirt] [RFC] Design executing commands from within domains

[Daniel P. Berrange]

On Tue, Aug 09, 2016 at 05:57:44PM +0800, Chen Hanxiao wrote:
> 
> At 2016-08-08 23:19:26, "Daniel P. Berrange" <berrange at redhat.com> wrote:
> >On Mon, Aug 08, 2016 at 05:00:38PM +0200, Michal Privoznik wrote:
> >> Dear list,
> >> 
> >> while wiring qemu-ga into libvirt I've noticed that it has ability to
> >> spawn commands inside guest. I haven't paid much attention to it then as
> >> implementing libvirt <-> qemu-ga communication was more important. But
> >> lately couple of requests on the list showed up where ability to spawn
> >> various commands inside guests would be much appreciated (e.g. when
> >> fetching some stats that HV can't know or has no support for yet -
> >> free/df/..).
> >> 
> >
> >I never really liked the qemu guest agent ability to run arbitrary commands.
> >It is basically re-inventing the shell but with really awful features. eg the
> >having to provide all the input  upfront, not having any  way to stream large
> >stdout/stderr data back to the host.
> >
> >Further, from a security POV it is really bad practice to have this feature
> >in QEMU guest agent, as it makes it impossible to provide any kind of sane
> >security confinment for the GA. IIRC, default Fedora SELinux policy will not
> >even permit the exec command to be to used. Most of the QEMU GA commands have
> >very tight scope so are easily confined, but 'exec' by its very nature wants
> >todo anything. From that POV, a general purpose exec facility is really better
> >suited to a separate command.
> 
> Users could ban it inside VM by blacklist.
> Also, with default SELinux policy, qga could not do anything more.
> So it's under control.

No, it really isn't satisfactory, because it does not enable you to separate
responsibilities.  ie the set of clients you want to grant 'exec' access to,
is not the same as the set of clients you want to give general QEMU guest
agent access to. By serving both use cases with the same agent, once you
allow 'exec' access for one use cases, you've not opened that avenue of
attack to all users of qemu guest agent.


If a general purpose 'exec' feature is desired, it can be achieved by doing
something as simple as running  mingetty  on a new well-defined virtio-serial
port. eg org.qemu.exec, and configuring that with PAM to not require a password
login.  That gives the client app full shell job control, I/O streaming, etc,
ie all the things that would be broken/impossible with trying to wrap the
qemu guest agent exec feature into an API.

> >Also from an API modelling POV, exposing the guest agent exec in libvirt
> >is pretty much giving up on any sense of API design. It'll just discourage
> >anyone from ever writing any further special case guest agent commands
> >with formal APIs.
> >
> >IOW, I don't think we should ever expose the qemu guest agent exec command
> >via libvirt APIs.
> 
> We've had qemuAgentCommand.
> So I think it's better for a new public API.

Thats in the libvirt-qemu.h file, so not something which has the same
long term support guarantee as formal public APIs. So existance of
that API is not justification to add a general guest exec to the main
libvirt API.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|