Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Least Privilege for xVM
1.2. Name of Document Author/Supplier:
Author: John Levon
1.3 Date of This Document:
29 April, 2008
4. Technical Description
4.1. Introduction
As originally introduced in PSARC/2006/260, the daemons run in
domain 0 are run as root with all privileges. This case seeks to
improve this situation to better meet the Solaris least-privilege
policy.
A patch binding is requested.
4.2. xVM daemons
In typical domain 0 operation, the following daemons are running:
xenstored
xenconsoled
xend
plus a 'qemu' instance for each running HVM domain.
We introduce a new user and group, 'xvm', both with ID 60. xenstored
and xenconsoled use __init_daemon_priv() to switch to this user and
further restrict the set of privileges needed. xend's privileges are
also reduced, but via the SMF manifest.
The following filesystem properties will be owned by xvm:xvm
/var/run/xend/
/var/run/xend/xmlrpc.sock [control socket]
/var/run/xend/boot/ [bootloader temp files]
/var/run/xenstored/
/var/run/xenstored/socket[_ro] [control sockets]
/var/run/xenstored/tdb [xenstore database]
/var/log/xen/ [log files]
/var/xen/dump/ [domain core files]
/var/lib/xend/
/var/lib/xend/domains [domain configs]
/var/lib/xend/storage [storage configs]
/var/lib/xend/xend-socket [control socket]
Startup scripts will perform the necessary permission fixes to
ensure that existing installations are upgraded correctly.
4.3. New xVM control privilege
A new privilege will be introduced:
privilege PRIV_XVM_CONTROL
Allows a process access to the xVM(5) control devices for
managing guest domains and the hypervisor. This privilege is
used only if booted into xVM on x86 platforms.
Currently this privilege is required to be in the effective set to
perform any read,write,ioctl, or mmap operations on the evtchn,privcmd,
and xenbus devices provided to domain 0 userspace.
Furthermore, the two daemons that listen for requests over local
UNIX sockets (xenstored and xend) are modified to require this
privilege from the peer, instead of the legacy behaviour of
requiring the peer to have uid 0. The relevant socket files will
have 666 permissions.
The xend implementation of this imports PSARC/2008/243.
4.4. New v12n management privilege
A second new privilege will be introduced:
privilege PRIV_VIRT_MANAGE
Allows a process to manage virtualized environments such as
xVM(5).
Neither privilege will be available to zones.
This privilege will be required to use all libvirt interfaces. To
implement this, virtd will be re-introduced and configured
to listen on a local domain socket. All libvirt calls will be routed
via virtd. virtd will run least-priv, but including PRIV_XVM_CONTROL
so it's able to talk to the hypervisor, xenstored, etc.
The advantage of this second privilege is that holders of it only
gain access to the libvirt API, which is much better defined than
that needed for direct Xen access. For example, a libvirt user
cannot perform arbitrary hypercalls, whereas PRIV_XVM_CONTROL allows
it. Additionally, libvirt is not Xen-specific, whereas PRIV_XVM_CONTROL
is necessarily so.
virtd will not be accessible remotely, and meets the SBD
requirements.
libvirt is modified to use 'xenconsole' directly to implement
its 'virsh console' command, as described later.
See xvm-priv.odg in the case materials.
4.5. Live migration
This case seeks to remove the obsolete /var/lib/xend/relocation-socket
This socket listens locally for live migration requests. As single-host
live migration is only useful for testing, and this is already
handled by the default settings of the TCP-based relocation
listener, this has no use. We are not aware of any users of this
socket.
4.6. Accessing a PV domain's console
Access to a PV domain's console currently requires root. This case
modifies the 'xenconsole' binary to be set-uid root. On
startup, it verifies that the real user has PRIV_XVM_CONTROL or
PRIV_VIRT_MANAGE. It then drops privilege and changes UID to the
invoking user. virsh will be modified to use xenconsole directly,
instead of interacting with the pseudo-console.
4.7. Accessing an HVM domain's console
As of today, any HVM console access is insecure. Even when listening
only on the localhost, any user can connect to the telnet port
providing serial access, or the VNC server. For the latter, an
insecure vncpasswd facility exists. As this is not at all secure, we
do not encourage its use.
However, this leaves the user with no way to securely access an
HVM domain's console. This case makes the following modifications:
If either console is configured to listen on localhost or 127.0.0.1
only, then any connected peers require PRIV_VIRT_MANAGE.
If either console is configured to listen on another address, then
connections are allowed by default. This is to allow remote VNC for
debugging, testing, and development purposes. Further work is
expected to provide a truly secure remote graphical console
facility.
The VNC server by default only listens on localhost. Setting an
config/vnc-listen parameter in xend's SMF service enables remote
access.
This also means that we can provide a default (empty) vncpasswd,
fixing a significant usability issue for HVM domains.
For example, setting a serial console as:
(serial 'telnet:localhost:2323,server,nowait')
will allow only local process with PRIV_VIRT_MANAGE to connect.
4.8. Accessing disks
qemu runs as a child of xend with least privilege. As a result, it
can't open root-owned files or devices. However, this is necessary
to provide emulated disk driver support. When the block tap feature
arrives, this will have the same issue.
Instead, as part of backend device hotplug, if the file or device is
owned by root, it will be chowned to the xvm user. Since qemu owns
the PRIV_FILE_DAC_READ/WRITE privileges, this is not necessary for
other ownership.
4.9. 'xm' and privileges
This case provides the framework for an otherwise unprivileged
interactive user to use the 'virsh' command line tool if they have
been granted the PRIV_VIRT_MANAGE privilege. We would also like to
enable this when using the legacy 'xm' tool, as work on
implementing all 'xm' functionality in 'virsh' is not yet complete.
Due to the implementation of 'xm', this requires certain parts of
the code to check for either privilege. For example, xenstored is
accessible with PRIV_XVM_CONTROL *or* PRIV_VIRT_MANAGE, since 'xm'
directly interacts with the store.
When 'xm' is finally deprecated, the check for PRIV_VIRT_MANAGE
can be removed, further increasing the privilege separation of the
system. A future case will specify this.
4.10. Authorizations
It has been noted that we should be acquiring a peer's uid, and
look that user up for a particular authorization, instead of
checking for effective privileges, in all the places where a
daemon is listening across a socket or network connection.
This implementation, however, does not use authorizations for the
following reasons:
- this case does not cover cmdline user privilege delegation, which
is the purpose of authorizations. A future case is expected to
define and use authorizations for the command-line user use-case.
- the actual advantages of checking for an authorization in this
case is not clear to me
- precedent for checking privileges in daemons exists in iscsitgtd,
dladmd and nscd
- existing precedent for checking authorizations only exists in
vscand and svc.configd, both of which are contacted by cmdline
utilities. No precedent for checking auths for non-user-level
socket listeners seems to exist
- the static approach of authorizations does not match
well with the dynamic nature of these daemons. In particular,
it makes privilege bracketing impossible for clients
- PRIV_XVM_CONTROL is implementation-specific and it does not make
sense to expose it to the user via authorizations. No cmdline
user should ever own this privilege (unless you have all privs)
- PRIV_XVM_CONTROL is x86-specific and will likely remain so. No
facility appears to exist for platform-specific authorizations.
- PRIV_VIRT_MANAGE is also being restricted at this stage. There
appears to be no facility for managing stability of
authorizations
- a single authorization is not possible, as we need a two-level
approach to split out the two privileges. As a result, an
additional user would be required for any non-cmdline client of
libvirt.
4.11. Effect on ldoms
On SPARC, libvirt interacts directly with ldm, the ldoms manager.
This expects two authorizations, solaris.ldoms.read/write. When
libvirt for SPARC integrates, it's expected that these privileges
will be granted to the user that virtd runs as (presumably 'xvm').
4.12. Future work
The privileges defined in this case are relatively coarse-grained.
Over time, we expect the privilege boundaries to be decomposed
further to improve the security surface of the control daemons.
virt-install(1m) will still require all privileges due to its use
of lofiadm(1). A forthcoming case will modify this requirement.
Authorizations, possibly with harmonization between ldoms and Xen,
should be defined to allow delegation for command line users.
Extension to an object-level authorization scheme will be
considered.
4.13. Interfaces exported
xvm:xvm user/group Project private
PRIV_XVM_CONTROL Project private
PRIV_VIRT_MANAGE Project private
All facilities provided in PSARC 2006/260 and PSARC 2007/157 are
provided, with the same classifications as before.
4.14. References
PSARC/2002/188 Least Privilege for Solaris
PSARC/2006/260 Solaris on Xen
PSARC/2007/157 libvirt
PSARC/2008/165 xVM Hypervisor Remote Access (virtd)
PSARC/2008/237 Libvirt for LDoms support
PSARC/2008/243 Python interface to ucred_get(3C)/getpeerucred(3C)
4.15. Man page diffs
--- xend.man Fri Apr 18 06:11:22 2008
+++ xend.new Fri Apr 18 06:16:19 2008
@@ -82,6 +82,22 @@
and can be processed with mdb(1). The default is true.
+ config/vncpasswd
+
+ Sets the password required by any client connecting to
+ a VNC session for a guest domain. Defaults to "" (no
+ password). VNC password authentication is not secure
+ and should not be used for securing guest domain consoles.
+
+ config/vnc-listen
+
+ Address to listen on for VNC connections. By default this
+ is "127.0.0.1", which has a special meaning: only users
+ or processes with the PRIV_VIRT_MANAGE privilege may
+ connect, and they must be logged on locally. If you set
+ this to any other value, then anyone will be able to
+ connect to VNC sessions, regardless of authorization.
+
config/xend-relocation-address
Address which xend listens on for relocation requests.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
