Wiki code for Service Management Facility (SMF) usage

Hide Line numbers
1: == Service Management Facility (SMF) usage
2: 
3: Copyright 1991-2007, Sun Microsystems, Inc
4: 
5: ||**Table of Contents**|**Overview**|**Policy Synopsis**
6: |
7: [[Applicability>>#Applicability]]
8: [[Background>>#Background]]
9: [[Policy>>#Policy]]
10: [[Advice>>#Advice]]
11: [[CaseHistory>>#CaseHistory]]
12: [[ManPages>>#ManPages]]
13: [[References>>#References]]
14: [[PolicyChangeLog>>#PolicyChangeLog]]
15: ||Category|Software.Solaris
16: |Owner|SAC
17: |Sponsor|Rich Green
18: |Author|Tasha Westmore
19: |Changes|smf-discuss
20: |Authority|SAC
21: |Policy Version|V1-1.5
22: |Status|Approved 2006/06/28
23: |Last Reviewed|28 June 2006
24: |Effective|Solaris 10 and later
25: | 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.
26: | |
27: ----
28: == Applicability
29: ----
30: == Background
31:  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.
32:  New and existing services delivered into SMF participate in and benefit from:
33: ** A unified model for delivery of services within Solaris
34: ** Services that are visible and manageable using smf-specific command-line utilities
35: ** Identification of misconfigured, misbehaving, and failed services
36: ** Automated restart (self-healing) of failed services in dependency order as the result of hardware and software faults, in addition to administrative error.
37: ** Consistent configuration handling via SMF’s Service Configuration Facility
38: ** Secure delegation of administration to non-root users
39:  SMF removes the developer’s dependency upon error prone /etc/rc?.d scripts and file-based system and service configurations within Solaris.
40:  This policy provides guidance to Solaris developers, programs, and projects regarding:
41: ** Criteria to determine when a project must deliver SMF services
42: ** Migration of "legacy" (existing) services to SMF
43: ** Requirements for delivery of SMF services (for any restarter, including svc.startd and inetd)
44: ** Requirements for delivery of new system and system service configuration
45: ----
46: == Policy
47: * **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:
48: ** /etc/init.d and rc?.d scripts
49: ** /etc/inittab entries
50: ** /etc/inetd.conf entries
51: ** /etc/default
52: ** /etc/* configuration files
53: * **Authority** SAC
54: * **Approval** PSARC 2002/547
55: * **Effective** Solaris 10 and later
56: * **Policy** 
57:  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:
58: ** /etc/init.d and rc?.d scripts
59: ** /etc/inittab entries
60: ** /etc/inetd.conf entries  and no new non-Private files in the following locations:
61: ** /etc/default
62: ** /etc/* configuration files
63:  Programs or projects providing a service or long-running application must participate in SMF by delivering services either in the form of a manifest (/var/svc/manifest directory hierarchy) or programatically.
64:  Integration of new or additional non-Private plain-text files within /etc/ hierarchy is no longer needed and is not allowed.
65: ==== Requirement for Legacy/Existing Services and Configuration
66:  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.
67:  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.
68: ==== Requirement for Integration of New Configuration Files
69:  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.
70: ==== Requirement for Integration of New Services
71:  Projects integrating new services within Solaris are required to participate in SMF and deliver an SMF service manifest representing their service.
72: ==== Guidance For Delivery of SMF Services
73: ** 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.
74: ** 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.
75: ** 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).
76:  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.
77: ** 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.
78: ** 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.
79: ** Projects which migrate legacy services to SMF must provide logic to enable the service on upgrade, when appropriate.
80: ** SMF services must be delivered "secure-by-default", see PSARC/2004/368 and Appendix D for detail.
81: ** Services must include an appropriate RBAC profile and set of authorizations for manipulating the service and its specific configuration.
82: ** Deliver appropriate template information with the SMF service. See smf_template(5) for more details.
83: *** Provide a short "common name" for the C locale and adhere to:
84: **** punctuation of any form must be avoided
85: **** capital letters must be used only for acronyms or proper names
86: **** a common name must consist only of printable characters
87: **** avoid using "service" as it is redundant
88: **** limit the name to under 40 characters
89: *** Refer to appropriate man pages or stable URLs for reference documentation
90: *** 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.
91: *** Do not provide template metadata for framework-defined property groups such as methods and dependencies.
92: ** Sun-delivered manifests must not be delivered to or placed within /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 /var/svc/manifest/site.
93: ** 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.
94: ** 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.
95:  Please contact [[smf-discuss@opensolaris.org>>mailto:smf-discuss@opensolaris.org]] for clarity with regard to the guidance provided within the policy or requests for review of your service manifest materials.
96: ----
97: == Advice
98: ===== Appendix A: Guidance for Highly Complex Configuration Grammar
99:  Projects that have:
100: ** Services with existing configuration files
101: ** Open Source services with well-known configuration files
102: ** Services that are recognized as having highly complex grammar ===== Appendix B: Guidance for "secret" configuration data
103:  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.
104:  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.
105:  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.
106:  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.
107:  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.
108: ===== Appendix C: Guidance for service instances delivered as "enabled"
109:  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.
110:  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.
111:  Any project delivering a service instance as "enabled" in the manifest must consult with the ARC for guidance.
112: ===== Appendix D: Guidance for Solaris network services
113:  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.
114: *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.
115: *1. Configure the manifest to disable the service by default.
116: *1. 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.
117: *1. Include an entry in the generic_limited_net profile that either disables the service or sets the local_only property.
118: *1. Network Services manifest example
119:  The manifest for a simple network service called myservice might look like this:
120: 
121: {{{
122:     <service_bundle type=’manifest’ name=’myservice’>
123:     <service
124:         name=’network/myservice’
125:         type=’service’
126:         version=’1’>
127:         <create_default_instance enabled=’false’>
128:         <exec_method
129:             type=’method’
130:             name=’start’
131:             exec=’/lib/svc/method/myservice’
132:             timeout_seconds=’10’ />
133:         <exec_method
134:             type=’method’
135:             name=’stop’
136:             exec=’:kill’
137:             timeout_seconds=’10’ />
138:         <exec_method
139:             type=’method’
140:             name=’refresh’
141:             exec=’:kill -HUP’
142:             timeout_seconds=’10’ />
143:         <property_group name=’general’ type=’framework’>
144:             <propval name=’action_authorization’ type=’astring’
145:                 value=’solaris.smf.manage.myservice’ />
146:             <!~--
147:                 If the authorization is intended to cover permanent
148:                 enable/disable as well as temporary, add the following
149:             ~-->
150:             <propval name=’value_authorization’ type=’astring’
151:                 value=’solaris.smf.manage.myservice’ />
152:         </property_group>
153:         <property_group name=’config’ type=’application’>
154:             <!~-- other application properties ~-->
155:             <propval
156:                 name=’local_only’
157:                 type=’boolean’
158:                 value=’false’ />
159:             <propval
160:                 name=’value_authorization’
161:                 type=’astring’
162:                 value=’solaris.smf.value.myservice’ />
163:         </property_group>
164:         <template>
165:             <common_name>
166:                 <loctext xml:lang=’C’>
167:                     my network service
168:                 </loctext>
169:             </common_name>
170:             <documentation>
171:                 <manpage title=’myservice’ section=’1M’ manpath=’/usr/share/man’ />
172:             </documentation>
173:         </template>
174:         </instance>
175:         <stability value=’Unstable’ />
176:     </service>
177:     </service_bundle>
178: }}}
179: 
180: ----
181: == CaseHistory
182: |=Case|=Type|=Name|=Comment
183: |[[/PSARC/2002/547>>Community Group arc.547]]|OnePager| Greenline  | Greenline
184: ----
185: == ManPages
186: |=Document|=Description
187: |libscf.3LIB|service configuration facility library
188: |rbac.5|role based access control
189: |smf.5|service management facility
190: |smf_method.5|SMF conventions for methods
191: |smf_restarter.5|SMF conventions for restarters
192: |smf_template.5|SMF template definition and conventions
193: |smf_security.5|SMF security behavior
194: |smf_bootstrap.5|SMF boot, packaging, and compatability behavior
195: |svc.configd.1M|SMF repository daemon
196: |svc.startd.1M|SMF master restarter
197: |svcs.1|report status of services
198: |svcadm.1M|manipulate service instances
199: |svccfg.1M|import, export, and modify service configurations
200: |svcprop.1M|retrieve service configuration properties
201: |privileges.5|process privilege model
202: ----
203: == References
204: ** [[ OpenSolaris SMF Community>>Community Group smf.WebHome]]
205: ** [[ Creating a Service Manifest>>http://www.sun.com/bigadmin/content/selfheal/sdev_intro.html]]
206: ** Service Manifest Examples (see svccfg(1M))
207: *** Sun-Delivered Conversions:
208: **** system/utmp
209: **** system/coreadm
210: **** network/telnet
211: *** OpenSolaris/External Conversions:
212: **** [[ http://www.opensolaris.org/os/community/smf/manifests/>>Community Group smf.manifests]]
213: ** [[ Best Practice: When to use setuid -vs- RBAC roles and profiles>>Community Group arc.rbac-intro]]
214: ** [[ Best Practice: Adding RBAC Authorizations>>Community Group arc.rbac-auths]]
215: ** [[ Best Practice: Building RBAC Rights Profiles>>Community Group arc.rbac-profiles]]
216: ** [[ OpenSolaris SMF Discussion Forum>>http://www.opensolaris.org/jive/forum.jspa?forumID=24]]
217: ** [[ BigAdmin Predictive Self-Healing Discussion Forum>>http://forum.sun.com/jive/forum.jspa?forumID=301]]
218: ----
219: == PolicyChangeLog
220: |=Version|=Date|=By|=Description
221: |1.5  |08/10/23  |lianep  |Updates from PSARC 2007/177 and 2008/350.  
222: |1.4  |07/12/05  |plocher  |Made references into URL links that reference OS.o  
223: |1.3  |07/07/19  |gww  |Add words for permanent enable/disable authorization  
224: |1.2  |07/02/09  |lianep  |Updates from PSARC 2007/084.  
225: |1.1  |06/07/25  |plocher  |date and time created 06/07/25 10:57:52 by plocher  
226: |
OpenSolaris

Top Menu

Wiki code for Service Management Facility (SMF) usage

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group arc Pages
