2008/165 xVM Hypervisor Remote Access (virtd)

[Jerry Gilliam]

Ryan has supplied an updated spec, included below.
The deliverables now no longer include the service and
do not start up the virtd daemon by default.

Marking this case as 'closed approved automatic' as this
resolves the issues brought up so far - thanks Darren
for helping out here!


-jg



xVM Hypervisor Remote Access (virtd)
====================================

1. Background

Part of the xVM gate [1] is libvirt, an LGPL library originally created by
Red Hat that gives applications access to different hypervisors.  See
http://www.libvirt.org/ for details.  Currently, the xVM gate contains
libvirt version 0.2.3.  Version 0.4.0 was released in December, and we plan
on putting this version back to the xVM gate along with Xen 3.1.2.

[1] - For those unfamiliar with the xVM gate, it is quite similar to the
onnv gate in terms of schedule and gatekeepers.  The source is available at
http://dlc.sun.com/osol/on/downloads/b84/xvm-src.tar.bz2

2. Remote Access

A new binary was introduced in 0.3.3: /usr/lib/virtd, which allows remote
access to the Xen hypervisor.  Since we skipped 0.3.3, we will be
introducing this binary with our putback of 0.4.0.

As an example, to access the hypervisor on remote machine foo, a user can
run:

	virsh -c xen+ssh://root@foo/

This creates a tunnel over ssh to the Xen hypervisor on the remote machine.

While the code is available to do this, the daemon will not be started by
default.  See Section 5 for more details.

3. Library Interfaces

Since there are no current users of the library outside of the xVM gate,
we do not feel it is necessary to list all of the APIs at this point.

Since these interfaces are controlled by an external body, a classification
of Volatile seems appropriate.  However, the creators of libvirt do seem to
pay attention to stability, so the project team may consider upgrading this
level as uses of this library increase in the future.

This case requests minor release binding.

----------------------------------------------------------------------------
| Interface			| Stability	| Comments		   |
+-------------------------------+---------------+--------------------------+
| /usr/lib/virtd		| Volatile	| xVM Remote Access Daemon |
| Library API Interfaces	| Volatile	|			   |
+-------------------------------+---------------+--------------------------+

4. Privilege

As described in the original Xen case, PSARC 2006/260, only root may access
the hypervisor.  libvirt 0.4.0 does include a framework to allow read-only
access to non-privileged users.  Implementing this on Solaris remains an
open task for the project team, depending on funding.  If completed, this
work will require a more detailed ARC case.

5. Security

The external version supplies four access mechanisms: TCP (plain text),
ssh, TLS, and unix sockets.  Plain text over TCP will be disabled because
it does not meet Secure By Default rules.  Unix sockets will be allowed,
but limited by directory permissions to root on the the local machine.  TLS
will also be disabled.  TLS support may or may not be added in the future
(with the additional ARC work if appropriate).  Initially, ssh will be the
only remote access method.

Given that only root may access the hypervisor, and ssh is the only access
method, the virtd daemon will be disabled until this can be improved.  This
case is simply to reserve the namespace; another case will be filed once
the daemon can be enabled in a secure manner.

6. Approval

Since this case represents a simple port of external code, we feel an
automatic self-approval is acceptable.