Hi Tony and others, I've attached the latest versions with the auths and method context. One question I do have is about updating prof_attr. Are there any rules surrounding how to update this file? Currently I've added solaris.sfm.manage.acpihpd to the "Maintenance and Repair" profile since it makes sense there but I could also create a separate profile just for this daemon and then also include it in "Maintenance and Repair". It seems odd to make a profile just for this one daemon.
I'd appreciate it if you could take a look. -------------- next part -------------- A non-text attachment was scrubbed... Name: acpihpd.xml Type: application/xml Size: 1999 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20091124/ee11636b/attachment.wsdl> -------------- next part -------------- Thanks, Mike On Nov 22, 2009, at 10:21 PM, Tony Nguyen wrote: > Mike, > > I had a look but the manifest contains neither the recommended > authorization properties nor method context. I'd be happy to review > once the team figure out the security model and implement the > authorization properties and method context. > > -tony > > Michael Corcoran wrote: >> Tony, >> >> I did include the manifest in my last email :) >> http://opensolaris.org/jive/thread.jspa?threadID=118317&tstart=0 >> is the thread on opensolaris.org. >> >> --Mike >> >> On Nov 20, 2009, at 5:07 PM, Tony Nguyen wrote: >> >>> Michael Corcoran wrote: >>>> Thanks for the help Alan, comments inline below. >>>> --Mike >>>> On Nov 20, 2009, at 1:52 AM, Alan Maguire wrote: >>>>> hi Mike >>>>> >>>>> Michael E. Corcoran wrote: >>>>>> Hi All, >>>>>> >>>>>> I'm working on a project where we have a new daemon that we >>>>>> want controlled by smf to support a specific hardware feature >>>>>> for a given platform. What we'd like would be to have this >>>>>> daemon start automatically and thus have it enabled by default, >>>>>> but this goes against the info at >>>>>> http://hub.opensolaris.org/bin/view/Community+Group+arc/SMF-policy >>>>>> >>>>>> "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." >>>>>> >>>>>> >>>>> The usual approach here is to have the service disabled by >>>>> default in >>>>> the manifest but to specify that it is to be enabled in one of >>>>> the profiles >>>>> specified in /var/svc/profile. >>>> Great. this makes sense. >>>>> These consist of customizations that are >>>>> activated in particular scenarios. You'd want to add >>>>> >>>>> <service name='mysvc' version='1' type='service'> >>>>> <instance name='default' enabled='true'/> >>>>> </service> >>>>> >>>>> The question is which profile to add this to - there are >>>>> platform-specific >>>>> profiles already, see usr/src/cmd/svc/profile in the ON gate for >>>>> examples. You probably want to add it to one of these. >>>> So how do these profiles get activated on a specific machine? It >>>> looks like we'll have to make a platform_i86pc.xml since none >>>> currently exists. >>> >>> On every boot, system/manifest-import applies a couple of system >>> profiles, platform is one of these profiles. For specifics, see >>> section 3 of /lib/svc/method/manifest-import. For x86 machines, >>> the current platform profile is a symlink to platform_none.xml >>> thus a new platform_i86pc.xml for x86 machine is reasonable. >>> >>>>> >>>>>> Our plan was to have it enabled by default on all x86 platforms >>>>>> and then have it exit and disable itself if it determines that >>>>>> hardware does not support this specific feature. So I'm >>>>>> assuming we need to go to PSARC to figure out if this approach >>>>>> is acceptable or is there a different ARC we'd be going to? >>>>>> >>>>>> >>>>>> I'm also unclear about >>>>>> "Services must include an appropriate RBAC profile and set of >>>>>> authorizations for manipulating the service and its specific >>>>>> configuration." >>>>>> >>>>>> If our service has no configuration, then I think we don't need >>>>>> the above. Is that correct? >>>>>> >>>>>> >>>>> There's two parts to this - manipulations of state and >>>>> manipulations >>>>> of configuration. You'd probably want an solaris.smf.manage >>>>> profile >>>>> which specifies auths needed to change state (i.e. to enable/ >>>>> disable). >>>>> This is done by adding the following to the manifest: >>>>> >>>>> <property_group name='general' type='framework'> >>>>> <!-- to start stop my service --> >>>>> <propval name='action_authorization' type='astring' >>>>> value='solaris.smf.manage.mysvc' /> >>>>> <propval name='value_authorization' type='astring' >>>>> value='solaris.smf.manage.mysvc' /> >>>>> </property_group> >>>> Can you point me at an example of such a profile? It's not clear >>>> to me what solaris.smf.manage.mysvc would look like. I'm >>>> guessing that it's just adding info to /etc/security/prof_attr >>>> and /etc/security/exec_attr as described in the privilege >>>> debugging doc on opensolaris.org. >>> >>> I believe you need to define a new auth in /etc/security/auth_attr >>> and optionally associate that auth to a profile in /etc/security/ >>> prof_attr. The service manifest uses the new auth to declare the >>> service's required authorization. See /var/svc/manifest/network/ >>> smtp-sendmail.xml for example. >>> >>>> Also, I'm assuming that I want this to be user daemon so how does >>>> that play into all of this? >>> >>> See Method Context section under smf_method(5) on setting >>> privileges for the service daemon. >>> >>> With respect to manifest reviewing, I'm sure one of us will have a >>> look if you send to this alias :) >>> >>> cheers, >>> -tony >> >
