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