Hi Gary,
Sorry for late reply, it took us sometime to figure out the
preferred way for acpihpd service.
> Then I think the open questions are:
> 1) what is the least user/group ids and privileges?
Acpihpd needs to call sysevent library, and libsysevent rejects
requests if the caller isn't root. So acpihpd must be run as root.
We are trying to use following method context for acpihpd.
<method_context>
<method_credential
user='root'
group='daemon'
privileges='basic,!proc_info,sys_config,sys_mount,sys_devices' />
</method_context>
> 2) how is the service enabled?
We will try to add a profile file for x86 platforms and enable
acpihpd in platform_x86.xml. And acpihpd will be set to disable
in acpihpd.xml by default.
> 3) is there any configuration?
Currently there's no configuration for acpihpd, so no special authorization
needed for accessing service properties.
For safety, we will add following authorization control for acpihpd.
<property_group name='general' type='framework'>
<propval name='action_authorization' type='astring'
value='solaris.smf.manage.acpihpd' />
<propval name='value_authorization' type='astring'
value='solaris.smf.manage.acpihpd' />
</property_group>
Thanks!
Gary Winiger <mailto:gww at eng.sun.com> wrote:
> Gerry,
>
>> Please also refer to inline comments below.
>> Thanks!
>> --Gerry
>>
>> Gary Winiger <mailto:gww at eng.sun.com> wrote:
>>> Mike,
>>>
>>>> I'm working with Intel to answer your questions. Essentially we
>>>> want to provide the least amount of access possible for this daemon
>>>> to do its job.
>>>
>>> IIRC, my initial question had 3 parts: How does the project meet
>>> the SMF requirement for authorizations to manage? What is the
>>> Method Context used to start the service? The service is to be
>> We haven't defined any method_environment, method_profile,
>> method_credential or method_context properties in the manifest file.
>> So it should use the default configuration, is that OK?
>
> Not really. The point is to meet the principle of least privilege.
> That is done with a method_context in the start method. The
> default method_context is euid=ruid=egid=rgid = 0, privs = all.
> Why is this required for this service? What above noaccess,
> privs = none is actually required?
>
>>> enabled only on the xxx platform - how is this done?
>> The service will be enabled on all x86 platforms. We provide an x86
>> specific package named SUNWacpihpd, which includes the service
>> manifest file for acpihpd. When installing the package, the acpihpd
>> service should be installed and enabled. So seems we don't need to
>> touch the platform profile file, is that true?
>
> I personally don't know about how the platform profiles are
> intended to be used. Contact the smf team about that. The
> SMF usage policy
> http://hub.opensolaris.org/bin/view/Community+Group+arc/SMF%2Dpolicy
> states:
> "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."
>
> So, it seems that the project team should address why and how
> the service is enabled.
>
>>> I'd like to clarify the first part about authorizations. When
>>> we talked I may not have been complete.
>>> If there are no properties that configure the service as in
>>> a property group of type application, there is no need for
>>> value authorizations to manage them.
>> Currently acpihpd service doesn't define any properties of category
>> "application", so seems we don't need to define the
>> "modify_authorization", "value_authorization" and
>> "read_authorization" security properties.
>> Is that true?
>
> "application" type property groups are not the only types that
> have configurable properties. The question is about any/all
> configurable properties. Property group types are arbitrary.
>
>>> If the service is never intended to be enabled/disabled by
>>> the administrator (but always enabled/started automatically
>>> at boot time and never disabled), there is no need for
>>> action/value authorizations to manage the service.
>> The service should always be enabled and not intended to be managed
>> by administrators.
>
> So there are no circumstances that the service should be disabled?
>
> Then I think the open questions are:
> 1) what is the least user/group ids and privileges?
> 2) how is the service enabled?
> 3) is there any configuration?
>
> Gary..
Liu Jiang (Gerry)
OpenSolaris, OTC, SSG, Intel
