From jg@jurassic.sfbay.sun.com Thu Feb 28 18:19:07 2008 Received: from jurassic.eng.sun.com (jurassic-226-b [129.146.226.130]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1T2J64k028421 for ; Thu, 28 Feb 2008 18:19:06 -0800 (PST) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id m1T2J6mK488208; Thu, 28 Feb 2008 18:19:06 -0800 (PST) Message-Id: <200802290219.m1T2J6mK488208@jurassic.eng.sun.com> Date: Thu, 28 Feb 2008 18:16:25 -0800 (PST) From: Jerry Gilliam Reply-To: Jerry Gilliam Subject: 2008/165 xVM Hypervisor Remote Access (virtd) To: psarc-ext@sac.sfbay.sun.com Cc: matrix-eng@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NOEPh4wMfKXuMljcIEPwtA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_78 SunOS 5.11 sun4u sparc Status: RO Content-Length: 3477 I am submitting this case on behalf of Ryan Scott with self-review approval, for which I believe it qualifies. If anyone feels otherwise I will promote this to a fast-track. The project requests minor/patch binding. thx, -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. virtd is implemented as the smf service svc:/system/xvm/virtd:default. This service depends on svc:/system/xvm/xend and svc:/system/xvm/console. 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 | | svc:/system/xvm/virtd:default | Volatile | smf service for virtd | | Library API Interfaces | Volatile | | +-------------------------------+---------------+--------------------------+ 4. 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. The combination of socket permissions and ssh authentication ensures that this project meets the Secure By Default rules. 5. 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. 6. Approval Since this case represents a simple port of external code, we feel an automatic self-approval is acceptable. From sacadmin Thu Feb 28 18:14:26 2008 Received: from tethys.sfbay.sun.com (tethys [129.146.226.92]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1T2EQAI028163; Thu, 28 Feb 2008 18:14:26 -0800 (PST) Received: from tethys.sfbay.sun.com (localhost [127.0.0.1]) by tethys.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1T2Biwe002016; Thu, 28 Feb 2008 18:11:44 -0800 (PST) Received: (from jg@localhost) by tethys.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1T2BiNM002012; Thu, 28 Feb 2008 18:11:44 -0800 (PST) Date: Thu, 28 Feb 2008 18:11:44 -0800 (PST) From: Jerry Gilliam Message-Id: <200802290211.m1T2BiNM002012@tethys.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: matrix-eng@sun.com Subject: xVM Hypervisor Remote Access (virtd) [PSARC/2008/165 FastTrack timeout 02/28/2008] Status: RO Content-Length: 571 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: xVM Hypervisor Remote Access (virtd) 1.2. Name of Document Author/Supplier: Author: Ryan Scott 1.3 Date of This Document: 28 February, 2008 4. Technical Description See the case directory for more detail 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 From Darren.Moffat@sun.com Fri Feb 29 03:41:59 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1TBfxoe010875 for ; Fri, 29 Feb 2008 03:41:59 -0800 (PST) Received: from gmp-eb-mail-2.sun.com (gmp-eb-mail-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1TBfvQq064289 for ; Fri, 29 Feb 2008 03:41:58 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1TBfqSs028586 for ; Fri, 29 Feb 2008 11:41:52 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWZ00601Y2DRU00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Fri, 29 Feb 2008 11:41:52 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX000CFF0HFFZ10@fe-emea-09.sun.com>; Fri, 29 Feb 2008 11:41:39 +0000 (GMT) Date: Fri, 29 Feb 2008 11:41:39 +0000 From: Darren J Moffat Subject: Re: 2008/165 xVM Hypervisor Remote Access (virtd) In-reply-to: <200802290219.m1T2J6mK488208@jurassic.eng.sun.com> Sender: Darren.Moffat@sun.com To: Jerry Gilliam Cc: psarc-ext@sac.sfbay.sun.com, matrix-eng@sun.com Message-id: <47C7EF73.7030003@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802290219.m1T2J6mK488208@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080116) Status: RO Content-Length: 510 As I understand it this case does not cause any new open ports since the only remote access method is the ssh based one. Incoming ssh as root is disabled (explicitly in /etc/ssh/sshd_config and on Indiana by root being a role) by default so it seems that this is not usable at all in the default configuration. What is going to be documented as the process for enabling this access ? Does the SMF virtd property have any properties for configuring which access methods are enabled ? -- Darren J Moffat From Ryan.Scott@sun.com Fri Feb 29 11:18:42 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1TJIgOt025732 for ; Fri, 29 Feb 2008 11:18:42 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1TJIfsj000952 for ; Fri, 29 Feb 2008 11:18:41 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1TJIai0016712 for ; Fri, 29 Feb 2008 11:18:36 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX000801LGY8500@fe-sfbay-09.sun.com> (original mail from Ryan.Scott@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Fri, 29 Feb 2008 11:18:36 -0800 (PST) Received: from [129.153.88.128] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX0003TLLMZGL30@fe-sfbay-09.sun.com>; Fri, 29 Feb 2008 11:18:36 -0800 (PST) Date: Fri, 29 Feb 2008 11:18:33 -0800 From: Ryan Scott Subject: Re: 2008/165 xVM Hypervisor Remote Access (virtd) In-reply-to: <47C7EF73.7030003@Sun.COM> Sender: Ryan.Scott@sun.com To: Darren J Moffat Cc: Jerry Gilliam , psarc-ext@sac.sfbay.sun.com, matrix-eng@sun.com Message-id: <47C85A89.8020203@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802290219.m1T2J6mK488208@jurassic.eng.sun.com> <47C7EF73.7030003@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 765 Darren J Moffat wrote: > As I understand it this case does not cause any new open ports since the > only remote access method is the ssh based one. > > Incoming ssh as root is disabled (explicitly in /etc/ssh/sshd_config and > on Indiana by root being a role) by default so it seems that this is not > usable at all in the default configuration. Correct. It does take administrator action before it can be used. > > What is going to be documented as the process for enabling this access ? For now, only the man page. See 6669828. > > Does the SMF virtd property have any properties for configuring which > access methods are enabled ? Currently, no, but I think that will be necessary for implementing tls access. -Ryan > > -- > Darren J Moffat From Darren.Moffat@sun.com Fri Feb 29 11:51:17 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1TJpHOe026308 for ; Fri, 29 Feb 2008 11:51:17 -0800 (PST) Received: from gmp-eb-mail-2.sun.com (gmp-eb-mail-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1TJpGwI019659 for ; Fri, 29 Feb 2008 11:51:17 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1TJpBSC015122 for ; Fri, 29 Feb 2008 19:51:11 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX000201N3DNQ00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Fri, 29 Feb 2008 19:51:10 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX000C2EN4PFZ30@fe-emea-09.sun.com>; Fri, 29 Feb 2008 19:50:50 +0000 (GMT) Date: Fri, 29 Feb 2008 19:50:49 +0000 From: Darren J Moffat Subject: Re: 2008/165 xVM Hypervisor Remote Access (virtd) In-reply-to: <47C85A89.8020203@Sun.COM> Sender: Darren.Moffat@sun.com To: Ryan Scott Cc: Jerry Gilliam , psarc-ext@sac.sfbay.sun.com, matrix-eng@sun.com Message-id: <47C86219.2040904@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802290219.m1T2J6mK488208@jurassic.eng.sun.com> <47C7EF73.7030003@Sun.COM> <47C85A89.8020203@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080116) Status: RO Content-Length: 868 Ryan Scott wrote: > Darren J Moffat wrote: >> As I understand it this case does not cause any new open ports since >> the only remote access method is the ssh based one. >> >> Incoming ssh as root is disabled (explicitly in /etc/ssh/sshd_config >> and on Indiana by root being a role) by default so it seems that this >> is not usable at all in the default configuration. > > Correct. It does take administrator action before it can be used. > >> >> What is going to be documented as the process for enabling this access ? > > For now, only the man page. See 6669828. Please don't recommend changing sshd_config so that root can login remotely since that opens up a lot more access than just the ability to talk to virtd. I think we need a better solution than that and as such I think this case should be put into waiting need spec. -- Darren J Moffat From jg@jurassic.sfbay.sun.com Mon Mar 3 14:28:58 2008 Received: from jurassic.eng.sun.com (jurassic-226-a [129.146.226.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m23MSw7a017670 for ; Mon, 3 Mar 2008 14:28:58 -0800 (PST) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id m23MSvna624001; Mon, 3 Mar 2008 14:28:57 -0800 (PST) Message-Id: <200803032228.m23MSvna624001@jurassic.eng.sun.com> Date: Mon, 3 Mar 2008 14:26:13 -0800 (PST) From: Jerry Gilliam Reply-To: Jerry Gilliam Subject: Re: 2008/165 xVM Hypervisor Remote Access (virtd) To: psarc-ext@sac.sfbay.sun.com, Ryan.Scott@sun.com Cc: matrix-eng@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BOqI7Rip1wS0RFD8CjhAqg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_78 SunOS 5.11 sun4u sparc Status: RO Content-Length: 3574 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.