Least Privilege for xVM 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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'). 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. 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. 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) 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.