If a program must be run by all users and it requires special
attributes (uid/gid or in the future privileges) they will need to
be "forced" on that program's executable (suid, sgid today).
If a program is to be run by only selected users and it requires
special attributes, from Solaris 8 forward, there are two ways for
this restriction to be accomplished. The program can itself verify
the user is an appropriate user of the program, or the user can be
granted the program with the required attributes. The tradeoff comes
in whether the program has reason to enforce multiple policies or
if there is but a single policy.
If the program enforces multiple policies, it probably should have the
special attributes "forced" on the program file. It should then
interpret authorizations granted to the user (chkauthattr(3secdb))
executing the program to determine which policies are approved for
the user. Making such decisions must be auditable for the Solaris
BSM configuration.
If there is just a single policy, the program should be placed
into a rights profile (prof_attr(4)) (or a new one created for the
program) with the appropriate special attributes (exec_attr(4))
(euid, ruid/euid, egid, rgid/egid today) and the profile assigned to
the users who should have be able to effectively run this program.
On a per-machine basis, profiles and authorizations (auth_attr(4))
can be granted to all users of a machine in the local policy.conf(4)
without having to grant them to individual users, or selectively to
individual users in user_attr(4) and prof_attr(4) local or name space
(nsswitch.conf(4)) databases. While authorizations can be granted in
either user_attr or prof_attr, it is preferred that they be granted in
prof_attr and that the profile be granted to the user through user_attr
(or for all users of a machine through policy.conf). The profile level
of abstraction makes for easier updates of authorizations and commands
in a changing environment.
Programs with "forced" attributes should bracket the user of these
attributes around their needed use. Today, for example, a suid program
should set its effective uid to its real at the beginning of main and
then only set the effective to the saved around any code that requires
the suid ID to succeed.