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

[Chen Hanxiao]

At 2016-08-09 19:02:18, "Daniel P. Berrange" <berrange at redhat.com> wrote:
>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.

That's a problem.
Although end user of VM could protect themselves by disable guest agent
or by --blacklist as RHEL did.

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

Thanks for your clarification.

Regards,
- Chen