I am sponsoring this fasttrack for John Levon. It is set to expire on 3/14/2007. Note that this is an externally visible case. liane --- SMF services for Xen 1. Introduction This case introduces the SMF services used by a Solaris-based domain 0 when running on Xen, or a Xen-compatible hypervisor. All of these services only run on domain 0 when booted under Xen virtualisation. A patch binding is requested. 2. Platform profiles As booting under Xen leaves the platform as i86pc (uname -m), and due to the issues described in 6447260 issues with platform_i86xen.xml profile, we cannot use a platform profile to enable these services. Instead, these services are delivered as disabled, and enabled via the contracted /var/lib/profile/upgrade method on next boot. When not booting under Xen (uname -i != "i86xpv"), the services will temporarily disable themselves and log a suitable message in the relevant log file under /var/svc/log/. The first service method to run will disable all three services in this case. When a better solution to this problem appears, the services will be modified to use it. Note that these services will only run as a result of an explicit user action, namely booting Solaris under Xen as a domain 0. In general, there is no reason to run as a domain 0 without making use of the control tools. All the services are standard contract services. 3. Xen Store Daemon /usr/lib/xenstored is a simple daemon implementing the database of configuration parameters for each virtual instance running, and has the FMRI: svc:/system/xctl/store:default. Due to significant Xen shortcomings, the daemon is not currently safely restartable; if it fails or is otherwise stopped, the Xen control tools as administered via xm will not work. See: 6447387 can''t restart xenstored It is dependent upon svc:/system/filesystem/local. 4. Xen Console Daemon /usr/lib/xenconsoled is also simple and acts as a virtual console server for each domain (excepting domain 0). It serves clients which connect via ''xm console <domain>''. Its FMRI is: svc:/system/xctl/console:default It is dependent upon svc:/system/xctl/xend:default. 5. Xen Control Daemon svc:/system/xctl/xend:default ''xend'' is the main centerpiece of the Xen control tools. It is used to keep track of domains the machine is running, and lives in /usr/lib/xend. It is dependent upon svc:/system/xctl/store. On other platforms, xend is configured via a (very) free-form file placed in /etc/xen/xend-config.sxp. Due to the difficulty in machine-reading the contents of this file for CAS scripts for upgrade, this case proposes to implement the configuration parameters as SMF properties from the outset. The risk in deviating from the standard configuration method found on other platforms is expected to be outweighed by the improved configuration facilities of SMF. The xend-config.sxp contains a number of configuration parameters that we do not represent as configurable at all on Solaris. Some of them constitute security risks, such as the HTTP server, and others do not seem to be useful at this time, such as the location of the log file. The names chosen reflect those in the xend-config.sxp file for simpler implementation and familiarity purposes. Thus, we are providing the following properties currently, which are all in the xend''s services ''config'' property group: enable-dump (default: true) Whether xend should generate domain core dumps if a domain under Xen control crashes. xend-unix-server (default: true) Whether xend should create UNIX sockets for communication with xend over HTTP. By default, xend provides an XML-RPC socket in /var/run/xend/xmlrpc.sock for communication. This option enables the creation of two UNIX sockets: /var/lib/xend/xend-socket /var/lib/xend/relocation-socket the former of which is for communication with xend, and the latter is used for the domain migration feature of Xen. Note that both of these interfaces are already considered as legacy by the community, although they are used by some external software such as libvirt; thus, for now, they should be provided (and in the unfortunate locations above). It is expected that all software will move to the new XML-RPC interface, work on which is underway. xend-relocation-server (default: true) Whether xend should listen on port 8002 for domain migration requests. xend-relocation-hosts-allow (default ''^localhost$'') A space-separated list of regular expressions. Any host matching any one of the regexps listed will be allowed to connect for domain migration if xend-relocation-server is enabled. dom0-min-mem (default: 196, units Mb) The minimum amount of memory reserved to the control domain, dom0. When starting domains, if there is not enough free memory available to the hypervisor to construct the domain, xend will ask dom0 to release memory it owns. This value is the limit on the amount of memory beyond which xend will request memory from dom0. dom0-cpus (default: 0) The number of physical CPUs dom0 is using. A value of 0 defaults to "use all physical CPUs". When xend starts, this value controls whether dom0 runs on all physical CPUs, or a subset (starting from CPU0 up to the value specified). This option can be used for physical partitioning of CPUs between the control domain and other domains. Note that this option does not change how many virtual CPUs dom0 has, which by default is equal to the number of physical CPUs (where physical corresponds with the Solaris kernel''s notion of a cpu_t). 6. Security issues Currently, as on other platforms, all of these daemons run as root with full privileges. Further work is underway to utilise least privilege and other Solaris security technologies to improve this situation. Additionally, the community is working on authentication schemes for access to the control tools as part of the ''xend API'' work. We intend to leverage this work as we track upstream development. In addition, no RBAC authorizations are being proposed in this case for the service and property administration of these FMRIs at this point in time. As there is no support for delegated administration in the rest of the Xen control stack at this point in time, this would be at best an attractive nuisance. (That is, there''s not much point in delegating control of xend''s properties when starting a domain instance requires root anyway). When further work is complete, RBAC facilities for these FMRIs will be detailed in a future case. 7. Interface table It is unclear that the interfaces provided in this document will remain stable as upstream community development continues. In particular, forthcoming releases are providing a radical new base for administrative remote access to the control tools. As a result, we feel that the interfaces described here are best represented by a classification of Volatile: svc:/system/xctl/store:default Volatile svc:/system/xctl/console:default Volatile svc:/system/xctl/xend:default Volatile svc:/system/xctl/xend:default (properties) Volatile /var/lib/xend/xend-socket Obsolete Volatile /var/lib/xend/xend-socket (wire protocol) Obsolete Volatile /var/lib/xend/relocation-socket Obsolete Volatile /var/lib/xend/relocation-socket (wire protocol) Obsolete Volatile 8. Man pages Man pages for xend, xenstored, and xenconsoled can be found in the materials. 9. References PSARC/2006/260 Solaris on Xen
what''s the case boundary here: the SMF services alone? These two defaults concern me: xend-relocation-server (default: true) Whether xend should listen on port 8002 for domain migration requests. xend-relocation-hosts-allow (default ''^localhost$'') A space-separated list of regular expressions. Any host matching any one of the regexps listed will be allowed to connect for domain migration if xend-relocation-server is enabled. is there value in a "null relocation"? if so, what is it? if not, why isn''t the acl empty? how exactly is the remote hostname determined and matched against this regexp?
(It''ll be easier for John to respond if I include him explicitly.) Bill Sommerfeld writes:> what''s the case boundary here: the SMF services alone?Yes.> These two defaults concern me:I''ll let John handle these.> > xend-relocation-server (default: true) > > Whether xend should listen on port 8002 for domain migration requests > . > > xend-relocation-hosts-allow (default ''^localhost$'') > > A space-separated list of regular expressions. Any host matching any > one of the regexps listed will be allowed to connect for domain > migration if xend-relocation-server is enabled. > > is there value in a "null relocation"? if so, what is it? if not, why isn''t > the acl empty? > how exactly is the remote hostname determined and matched against this regexp > ?
On Tue, Mar 06, 2007 at 06:40:39PM -0500, Bill Sommerfeld wrote:> These two defaults concern me: > > xend-relocation-server (default: true) > > Whether xend should listen on port 8002 for domain migration requests. > > xend-relocation-hosts-allow (default ''^localhost$'') > > A space-separated list of regular expressions. Any host matching any > one of the regexps listed will be allowed to connect for domain > migration if xend-relocation-server is enabled. > > is there value in a "null relocation"? if so, what is it?It''s very useful for testing, and this value mirrors the community upstream''s default. Furthermore, a NULL value corresponds to allowing everything in. A far from marvellous implementation.> how exactly is the remote hostname determined and matched against this regexp?Like this: def hostAllowed(addrport, hosts_allowed): if hosts_allowed is None: return True else: fqdn = socket.getfqdn(addrport[0]) for h in hosts_allowed: if h.match(fqdn) or h.match(addrport[0]): return True log.warn("Rejected connection from %s (%s).", addrport[0], fqdn) The Python docs (http://pydoc.org/2.4.1/socket.html#-getfqdn) state: getfqdn(name='''') Get fully qualified domain name from name. An empty argument is interpreted as meaning the local host. First the hostname returned by gethostbyaddr() is checked, then possibly existing aliases. In case no FQDN is available, hostname is returned. Let me know if you''d like further details here. As mentioned in the case, we''re distinctly unhappy the current situation, as are the community from what I can gather. At this point, though, there''s nothing better available without significant (and incompatible with everyone else!) work. regards, john
On Wed, 2007-03-07 at 00:12 +0000, John Levon wrote:> getfqdn(name='''') > Get fully qualified domain name from name. > > An empty argument is interpreted as meaning the local host. > > First the hostname returned by gethostbyaddr() is checked, then > possibly existing aliases. In case no FQDN is available, hostname > is returned. > > Let me know if you''d like further details here.I don''t believe that this is an airtight way of constraining this service to local use only. I think you''d be far safer binding the socket to 127.0.0.1 by default; relying on gethostbyaddr() to only return "localhost" for a loopback address doesn''t strike me as particularly clever. - Bill
On Tue, Mar 06, 2007 at 07:27:51PM -0500, Bill Sommerfeld wrote:> I don''t believe that this is an airtight way of constraining this > service to local use only. > > I think you''d be far safer binding the socket to 127.0.0.1 by default; > relying on gethostbyaddr() to only return "localhost" for a loopback > address doesn''t strike me as particularly clever.A default of 127.0.0.1 is fine by me; I''ll verify this works correctly. thanks, john
>I think you''d be far safer binding the socket to 127.0.0.1 by default; >relying on gethostbyaddr() to only return "localhost" for a loopback >address doesn''t strike me as particularly clever.getpeerucred() in S10+ and verifying that the call comes in from a local zone is an airtight way. Casper
On 03/07/07 08:57, Casper.Dik@Sun.COM wrote:>>I think you''d be far safer binding the socket to 127.0.0.1 by default; >>relying on gethostbyaddr() to only return "localhost" for a loopback >>address doesn''t strike me as particularly clever. > > getpeerucred() in S10+ and verifying that the call comes in from a local > zone is an airtight way.I think that''ll still show the port as open to portscanners, not? Binding to 127.0.0.1 seems a lesser call generator. Joep
Liane Praza wrote:> 6. Security issues > > Currently, as on other platforms, all of these daemons run as root with > full privileges. Further work is underway to utilise least privilege and > other Solaris security technologies to improve this situation.Do we have a timeframe for when we can expect this to be done ? Note that a perfectly acceptable first cut of this does not require modification of the code. Just use the Privilege Debugging Blueprint and the tool that is with it to determine what privileges are actually used and use that as the initial set that SMF gives to the start method.> Additionally, the community is working on authentication schemes for > access to the control tools as part of the ''xend API'' work. We intend to > leverage this work as we track upstream development.Timeframe ?> In addition, no RBAC authorizations are being proposed in this case for the > service and property administration of these FMRIs at this point in time. > As there is no support for delegated administration in the rest of the Xen > control stack at this point in time, this would be at best an attractive > nuisance. (That is, there''s not much point in delegating control of xend''s > properties when starting a domain instance requires root anyway). When > further work is complete, RBAC facilities for these FMRIs will be detailed > in a future case.This isn''t acceptable to me. In fact I''d assert exactly the opposite. Preciesly because Xen has no delegated admin system of its own there should be an RBAC execution profile for running the Xen admin commands and the rights profile should contain the RBAC authorisations used to control the SMF services. For example if there is an admin command that needs to be run with all privilege then that should be in an RBAC profile. This should have been covered in the main Xen case, for me though this case makes it very clear that was probably missed. -- Darren J Moffat
On Wed, Mar 07, 2007 at 12:43:43AM +0000, John Levon wrote:> > I don''t believe that this is an airtight way of constraining this > > service to local use only. > > > > I think you''d be far safer binding the socket to 127.0.0.1 by default; > > relying on gethostbyaddr() to only return "localhost" for a loopback > > address doesn''t strike me as particularly clever. > > A default of 127.0.0.1 is fine by me; I''ll verify this works correctly.I totally misread you last night, apologies. Let me start again. This seems fine; I intend to add: xend-relocation-address (default: 127.0.0.1) Which address the relocation should bind to if enabled. Seem OK? regards john
On Wed, Mar 07, 2007 at 10:51:35AM +0000, Darren J Moffat wrote:> > Currently, as on other platforms, all of these daemons run as root with > > full privileges. Further work is underway to utilise least privilege > > and > > other Solaris security technologies to improve this situation. > > Do we have a timeframe for when we can expect this to be done ?No. It''s a significant amount of work.> Note that a perfectly acceptable first cut of this does not require > modification of the code. Just use the Privilege Debugging Blueprint > and the tool that is with it to determine what privileges are actually > used and use that as the initial set that SMF gives to the start method.We can do that if it''s seen as useful. We will still need to run as euid=0 though: PRIV_FILE_DAC_WRITE Allow a process to write a file or directory whose per- mission bits or ACL do not allow the process write per- mission. All privileges are required to write files owned by UID 0 in the absence of an effective UID of 0. Given the nature of the privcmd driver it''s not so much "least privilege" as "a bit less privilege".> > Additionally, the community is working on authentication schemes for > > access to the control tools as part of the ''xend API'' work. We intend to > > leverage this work as we track upstream development. > > Timeframe ?The API work will be available in Xen 3.0.5, expected some time this month. More work would be needed after that though, as it doesn''t provide a meaningful auth scheme yet.> Preciesly because Xen has no delegated admin system of its own there > should be an RBAC execution profile for running the Xen admin commands > and the rights profile should contain the RBAC authorisations used to > control the SMF services. > > For example if there is an admin command that needs to be run with all > privilege then that should be in an RBAC profile.If it''s seen as useful to have an RBAC profile that gets pretty close to complete control over the machine (reducing available memory, allowing any remote machine to migrate a guest to it, complete control over any/all hosted domains), then sure, we can have this.> This should have been covered in the main Xen case, for me though this > case makes it very clear that was probably missed.The current situation was identified in the materials. john
* Danek Duvall <danek.duvall@sun.com> [2007-03-08 15:10]:> On Tue, Mar 06, 2007 at 03:20:49PM -0800, Liane Praza wrote: > > > svc:/system/xctl/store:default Volatile > > svc:/system/xctl/console:default Volatile > > svc:/system/xctl/xend:default Volatile > > I know this is a nit, but "xctl" seems a bit too cryptic to me. Would > simply "xen" not work there? Or if that''s somehow too generic, "xenctl"?No. Please leave this alone. Happy to explain in person. tim
Tim Marsland wrote:> * Danek Duvall <danek.duvall@sun.com> [2007-03-08 15:10]: >> On Tue, Mar 06, 2007 at 03:20:49PM -0800, Liane Praza wrote: >> >>> svc:/system/xctl/store:default Volatile >>> svc:/system/xctl/console:default Volatile >>> svc:/system/xctl/xend:default Volatile >> I know this is a nit, but "xctl" seems a bit too cryptic to me. Would >> simply "xen" not work there? Or if that''s somehow too generic, "xenctl"? > > No. Please leave this alone. Happy to explain in person.For those of us that don''t have the luxury of Tim explaining this to us in person... http://mail.opensolaris.org/pipermail/xen-discuss/2007-January/000349.html Was the comment when this same issue was discussed based on a draft of this case. -- Rich
John Levon writes:> This seems > fine; I intend to add: > > xend-relocation-address (default: 127.0.0.1) > > Which address the relocation should bind to if enabled.I''ve updated the spec.txt and xend.man files in the materials directory to reflect this change. liane
This fasttrack was approved (contingent on Gary''s review, which is now complete) at Wednesday''s PSARC meeting. liane
hi, How to connect to remote machines hypervisor in Solaris xen using xm -c ? Thanks Ajeesh This message posted from opensolaris.org
Ajeeshrao.r wrote:> hi, > > How to connect to remote machines hypervisor in Solaris xen using xm -c ?That is not supported from xm. When we putback the Xen 3.1.x bits (hopefully in a lowish 80''s build), you will be able to do the following.. virsh -c xen+ssh://root@<dom0 ip addr>/ MRJ