David Powell wrote:
> Scott Rotondo wrote:
>> I fully support the changes described here, but I have a couple of
>> comments/questions about minor details.
>>
>> 1. The man page should document the specific authorizations needed,
>> just as it used to document the specific privilege. It's fine to
>> mention that the Maintenance and Repair profile provides these
>> authorizations, but they could be provided by other profiles also. [In
>> other words, the authorization name is the real interface, not the
>> profile name.]
>>
>>> Multiple -e and -d options can be specified on
>>> - the command line. Only users with the sys_admin
>>> - privilege can use this option.
>>> + the command line. Only users and roles belonging
>>> + to the "Maintenance and Repair" RBAC profile can
>>> + use this option.
>>
>> Suggest: Only users and roles with the solaris.smf.manage.coreadm and
>> solaris.smf.value.coreadm authorizations can use this option.
>
> When researching the case, I was advised to look at the dladm man
> page. It takes the approach of documenting the necessary profile.
>
> I'm not wedded to either approach, though I have to say that the
> profile has the appeal of being an interface that can be more easily
> maintained in the face of implementation changes. i.e. if the
> previously documented mechanism actually worked, I would have been
> more concerned about changing coreadm from requiring privileges to
> requiring authorizations. If it had been documented in terms of the
> profile, there would be no cause for concern regardless of the
> change.
>
> Given this, the precedent set by dladm, and that in the common case
> coreadm users should just be using the provided profile (i.e.
> referring first to the profile makes the man page more useful
> documentation), would it instead be acceptable to document the
> authorizations in an auxiliary section (e.g. NOTES) leaving the
> profile as the "primary" documented interface?
So apparently there is more divided opinion on this issue than I
thought. Who would have guessed? ;-)
I think that individual privilege and authorization names should be the
stable interfaces presented to administrators rather than the names of
RBAC profiles that contain them. My reasons for this view include the
following:
1. There are other, equally valid, ways for users to acquire
authorizations and processes to acquire privileges besides the use of
RBAC profiles. Individual privileges and authorizations can be specified
in user_attr entries and in SMF service manifests. Many processes also
gain privileges by running with uid 0.
2. There is no intent to prevent overlap between RBAC profiles. The same
authorization, for example, may be granted by multiple profiles included
in Solaris, as well as additional ones defined by the user. In such an
environment, there is no obvious rationale for selecting which profile
to specify on a man page like this one.
3. Authorizations and privileges exist in order to allow an
administrator to implement the principle of least privilege, i.e. to
grant a minimal set of rights needed to accomplish a particular purpose.
In order to construct such a set, an administrator needs to know the
function of each privilege or authorization and needs to know which ones
are required by each administrative program.
4. Privilege names, at least, cannot be considered as implementation
details that are subject to change within an RBAC profile because the
specific privileges are documented on the man pages of system calls that
require them. Although this argument does not apply to authorizations, I
think they should be treated similarly for the reasons described above.
Having said all that, this is a general architectural issue that should
not hold up the current fast-track. PSARC members: What is the best
mechanism to reach consensus on this issue and ensure that current and
future documentation complies with that consensus?
Scott
