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 >
