ARC Policies » Service Management Facility (SMF) usage
en

Service Management Facility (SMF) usage

Service Management Facility (SMF) usage

Copyright 1991-2007, Sun Microsystems, Inc

Policy Synopsis

This policy positions the Service Management Facility (see PSARC/2002/547 Greenline), smf(5), as the primary infrastructure for service management and primary repository for system and service configuration within Solaris.

Contents

Overview

OwnerSAC
SponsorRich Green
AuthorTasha Westmore
Changessmf-discuss
AuthoritySAC
Policy VersionV1-1.6
StatusApproved 2006/06/28
Last Reviewed28 June 2006
EffectiveSolaris 10 and later

Applicability

All software that traditionally resides within or modifies system startup and initialization is impacted and must adhere to the guidelines and requirements of this policy.

Background

 The purpose of this policy is to promote the Service Management Facility (see PSARC/2002/547 Greenline), smf(5), as the primary infrastructure for service management and primary repository for system and service configuration within Solaris.

New and existing services delivered into SMF participate in and benefit from:

  • A unified model for delivery of services within Solaris
  • Services that are visible and manageable using smf-specific command-line utilities
  • Identification of misconfigured, misbehaving, and failed services
  • Automated restart (self-healing) of failed services in dependency order as the result of hardware and software faults, in addition to administrative error.
  • Consistent configuration handling via SMF's Service Configuration Facility
  • Secure delegation of administration to non-root users

SMF removes the developer's dependency upon error prone /etc/rc?.d scripts and file-based system and service configurations within Solaris.

This policy provides guidance to Solaris developers, programs, and projects regarding:

  • Criteria to determine when a project must deliver SMF services
  • Migration of "legacy" (existing) services to SMF
  • Requirements for delivery of SMF services (for any restarter, including svc.startd and inetd)
  • Requirements for delivery of new system and system service configuration

Policy

  • Applies to  This policy applies to you if you create or modify SMF services (for any restarter, including svc.startd and inetd). This policy also applies to you if you create, modify or use files in any of these locations:
    • /etc/init.d and rc?.d scripts
    • /etc/inittab entries
    • /etc/inetd.conf entries
    • /etc/default
    • /etc/* configuration files
  • Authority SAC
  • Approval PSARC 2002/547
  • Effective Solaris 10 and later
  • Policy

    With the introduction of the Service Management Facility (SMF), smf(5), this policy requires that there must be no new files or modifications to the following locations:

    • /etc/init.d and rc?.d scripts
    • /etc/inittab entries
    • /etc/inetd.conf entries and no new non-Private files in the following locations:
    • /etc/default
    • /etc/* configuration files

    Programs or projects providing a service or long-running application must participate in SMF by delivering services either in the form of a manifest (/lib/svc/manifest directory hierarchy) or programatically.

    Integration of new or additional non-Private plain-text files within /etc/ hierarchy is no longer needed and is not allowed.

    Requirement for Legacy/Existing Services and Configuration

    This policy defines a "legacy" service as a long-running software object currently reliant upon the traditional start-up mechanisms (i.e., /etc/init.d, rc scripts, etc) and integrated prior to the introduction of SMF but have not presently migrated.

    Legacy services and their configuration files must transition to SMF prior to any additional or subsequent modifications to the service being approved. Projects dealing with legacy services must consult with the ARC as a part of the review process to determine next steps and appropriate timelines for conversion.

    Requirement for Integration of New Configuration Files

    Projects intending to integrate new system or service configuration files (which traditionally reside within the /etc/* directory hierarchy) into Solaris must use the Service Configuration Facility (SCF), libscf(3LIB), as their repository for system configuration. Projects impacted by Appendicies A and B, must consult with the ARC to determine if this aspect of the policy is applicable.

    Requirement for Integration of New Services

    Projects integrating new services within Solaris are required to participate in SMF and deliver an SMF service manifest representing their service.

    Guidance For Delivery of SMF Services

    • Services must be delivered (by manifest or programatically) disabled by default to align with Sun's security goals. Projects impacted by Appendix C, must consult with the ARC to determine if this aspect of the policy is applicable.
    • Services must be configured to run with the most restricted context and with the least possible privileges. See privileges(5), smf_method(5) for additional details.
    • Services must provide service related RBAC authorizations, as appropriate, by providing service specific values for the action_authorization, modify_authorization, value_authorization, and read_authorization of property groups. See smf_security(5).
      These authorizations must follow the form of "solaris.smf.{manage, modify, value, read}.service" respectively. These authorizations must be delivered into an appropriate Rights profile, either new or existing.
    • Service instances bundled with Solaris must be included in an appropriate set of service profiles. Unbundled software should enable its services at an appropriate point in the software installer's configuration logic.
    • Service method scripts must be delivered as "read-only" and any customizable settings must be accessible via a service-specific property or existing service configuration file.
    • Projects which migrate legacy services to SMF must provide logic to enable the service on upgrade, when appropriate.
    • SMF services must be delivered "secure-by-default", see PSARC/2004/368 and Appendix D for detail.
    • Services must include an appropriate RBAC profile and set of authorizations for manipulating the service and its specific configuration.
    • Deliver appropriate template information with the SMF service. See smf_template(5) for more details.
      • Provide a short "common name" for the C locale and adhere to:
        • punctuation of any form must be avoided
        • capital letters must be used only for acronyms or proper names
        • a common name must consist only of printable characters
        • avoid using "service" as it is redundant
        • limit the name to under 40 characters
      • Refer to appropriate man pages or stable URLs for reference documentation
      • Provide template metadata including common_names, descriptions, choices and constraints for service-specific property groups and properties you introduce. At a minimum, provide descriptions for property groups and properties in the C locale.
      • Do not provide template metadata for framework-defined property groups such as methods and dependencies.
    • Sun-delivered manifests must not be delivered to or placed within /lib/svc/manifest/site or /var/svc/manifest/site. The 'site' FMRI category and site-local manifests are reserved exclusively for customer use, therefore Sun-delivered services must not use the "svc:/site/*" FMRI nor should Sun-delivered manifests reside in /lib/svc/manifest/site or /var/svc/manifest/site.
    • Service configuration stored in the repository must be represented using distinct, documented properties. Catch-all properties for things like command line arguments are not allowed.
    • Application properties for non-ordered lists of values must use SMF multi-valued properties and not embed multiple application values in a single SMF value.

    Please contact smf-discuss@opensolaris.org for clarity with regard to the guidance provided within the policy or requests for review of your service manifest materials.

Advice

Appendix A: Guidance for Highly Complex Configuration Grammar

Projects that have:

  • Services with existing configuration files
  • Open Source services with well-known configuration files
  • Services that are recognized as having highly complex grammar must consult with the ARC to determine if utilizing the Service Configuration Facility is appropriate for their specific configuration data.

Appendix B: Guidance for "secret" configuration data

It should be noted that configuration data residing in the SCF repository is world-readable by default. Projects with configuration data that is deemed protected in nature or that should remain private from a security standpoint must consult with the ARC to determine if the Service Configuration Facility is the appropriate repository for their data. If so, the property group(s) intended to contain protected data must be defined in manifests with an appropriate read_authorization property (see smf_security(5)), and no protected information may be delivered in the manifest itself.

Use of this facilty to store secrets in the clear without additional practices does not implement all of the recommendations of the existing Best Practice for password storage. While this may be no worse than existing behavior in some cases, it is possible to do better; accordngly, applications using this facility should carefully review the Best Practice and apply relevant additional protections.

In addition, since SMF access control is applied at the property group level, applications must segregate non-public properties into separate read-protected property groups. To avoid the need to grant authorizations too widely, properties which do not need read protection should not be placed in read-protected property groups.

Applications creating read-protected property groups should set the read_authorization during initial install through the import of a service manifest. Service manifests delivered as part of the installation of a software package must not permit operation using placeholder sensitive values; services dependent on these values must behave in a safe manner (typically by denying access) until the sensitive value is appropriately initialized for real.

In the event that read-protected property groups are created by other means (for instance, to store per-service-instance data for a dynamically changing set of service instances), the read_authorization property must be set before any sensitive data is stored to ensure there is no window of time where the sensitive values are unprotected.

Appendix C: Guidance for service instances delivered as "enabled"

Under most circumstances, service manifests should specify their service instances as "disabled". This decouples the policy of whether to start a service from the installation/creation of the service, allowing administrative control of the services offered by the system.

Service profiles are used to enable Solaris-bundled services. (See "profile application" in smf_bootstrap(5).) Which services are enabled or disabled may be further customized by administrators through profiles. Services which must be started in order for initial profile application to complete must be enabled in the service manifest.

Any project delivering a service instance as "enabled" in the manifest must consult with the ARC for guidance.

Appendix D: Guidance for Solaris network services

Network services in Solaris need to be designed to comply with the Network Install Time Security policy at http://sac.sfbay.sun.com/swg/Security/Policy/NITS.html. The following guidelines establish Solaris conventions for services to comply with this policy.

  1. Use SMF to control the service. This involves creating an SMF manifest that specifies properties of the service such as dependencies on other services. Include a solaris.smf.manage. authorization to allow this service to be enabled and disabled.
  2. Configure the manifest to disable the service by default.
  3. If the service needs to be used by local clients, provide an SMF property that restricts the service to accept local requests only. By convention, this should be a boolean property called config/local_only. Include a solaris.smf.value. authorization to allow this and other properties to be modified. The man page for the service should describe the property and explain how to modify it and restart the service. There are several ways for the service to interpret the local_only property. It could bind to a local socket (e.g. 127.0.0.1), use a loopback transport such as ticots or ticlts, or use a mechanism such as tcp_wrappers to restrict the client connections that are accepted.
  4. Include an entry in the generic_limited_net profile that either disables the service or sets the local_only property.
  5. Network Services manifest example

    The manifest for a simple network service called myservice might look like this:

        <service_bundle type='manifest' name='myservice'>
    <service
        name='network/myservice'
        type='service'
        version='1'>
        <create_default_instance enabled='false'>
        <exec_method
            type='method'
            name='start'
            exec='/lib/svc/method/myservice'
            timeout_seconds='10' />
        <exec_method
            type='method'
            name='stop'
            exec=':kill'
            timeout_seconds='10' />
        <exec_method
            type='method'
            name='refresh'
            exec=':kill -HUP'
            timeout_seconds='10' />
        <property_group name='general' type='framework'>
            <propval name='action_authorization' type='astring'
                value='solaris.smf.manage.myservice' />
            <!~--
                If the authorization is intended to cover permanent
                enable/disable as well as temporary, add the following
            ~-->
            <propval name='value_authorization' type='astring'
                value='solaris.smf.manage.myservice' />
        </property_group>
        <property_group name='config' type='application'>
            <!~-- other application properties ~-->
            <propval
                name='local_only'
                type='boolean'
                value='false' />
            <propval
                name='value_authorization'
                type='astring'
                value='solaris.smf.value.myservice' />
        </property_group>
        <template>
            <common_name>
                <loctext xml:lang='C'>
                    my network service
                </loctext>
            </common_name>
            <documentation>
                <manpage title='myservice' section='1M' manpath='/usr/share/man' />
            </documentation>
        </template>
        </instance>
        <stability value='Unstable' />
    </service>
    </service_bundle>

Appendix E: Guidance for placement of manifests

SMF manifests should be placed under /lib/svc/manifest to take advantage of early manifest import.  /var/svc/manifest is supported for backward compatibility, but its use is now discouraged.  At some point in the future, support for placing manifests in /var/svc/manifest may be withdrawn.

CaseHistory

CaseTypeNameComment
PSARC/2002/547OnePager Greenline  
PSARC/2007/177FastTrack SMF Sensitive Properties 
PSARC/2008/350FastTrack SMF Templates 
PSARC/2010/013FastTrack Early Manifest Import 

ManPages

DocumentDescription
libscf.3LIBservice configuration facility library
rbac.5role based access control
smf.5service management facility
smf_method.5SMF conventions for methods
smf_restarter.5SMF conventions for restarters
smf_template.5SMF template definition and conventions
smf_security.5SMF security behavior
smf_bootstrap.5SMF boot, packaging, and compatability behavior
svc.configd.1MSMF repository daemon
svc.startd.1MSMF master restarter
svcs.1report status of services
svcadm.1Mmanipulate service instances
svccfg.1Mimport, export, and modify service configurations
svcprop.1Mretrieve service configuration properties
privileges.5process privilege model

References

PolicyChangeLog

VersionDateByDescription
1.6  10/04/08  lianep  Changes for PSARC/2010/013.  
1.5  08/10/23  lianep  Updates from PSARC 2007/177 and 2008/350.  
1.4  07/12/05  plocher  Made references into URL links that reference OS.o  
1.3  07/07/19  gww  Add words for permanent enable/disable authorization  
1.2  07/02/09  lianep  Updates from PSARC 2007/084.  
1.1  06/07/25  plocher  date and time created 06/07/25 10:57:52 by plocher  
Tags:
Created by admin on 2009/10/26 12:07
Last modified by Liane Praza on 2010/04/10 15:31

Collectives

Community Group arc Pages

XWiki Enterprise 2.7.1.34853 - Documentation