System Security, Roles, and Rights Profiles
RolesSolaris Management Console in Trusted Solaris
Hierarchies of Rights Profiles
Trusted Solaris and Solaris provide role-based access control (RBAC) as an alternative to the traditional all-or-nothing system administration model. On traditional systems, even the simplest tasks (such as setting the system date) must be done by a highly trusted user, because root login gives access to all aspects of the system. Anyone who learns the root password can log in and do just about anything anonymously.
In contrast, a system with RBAC enabled is administered by multiple administrators with separate responsibilities, none of whom have total control of the system. With RBAC, root access is no longer required for administration.
No one can do administrative work anonymously because a user must log in first and identify himself or herself before assuming a role. Actions performed while in the role are identified with the role's id instead of the id of the logged-in user, but to allow the actions performed in a role to be traced back to the responsible user, the user's id is maintained as an audit id.
RBAC divides administrative tasks among three recommended roles, and a site using RBAC can reconfigure the role responsibilities to any desired degree of granularity.
Another advantage in Trusted Solaris is that administrative work is performed through the trusted path, which provides a means to perform security-relevant operations with assurance that you are not being spoofed and that keystrokes and windows cannot be viewed by untrusted processes. A role is assumed through the Trusted Path menu, and once the role is assumed, the role's work is performed in an administrative role workspace with the trusted path
A role can only do tasks that are defined for that role, because each role is restricted to using only the minimum set of tools required to do those tasks. The needed tools (commands, CDE actions, and authorizations) are collected in rights profiles. Rights profiles control not only what roles are able to do but also what any user is allowed to do on the system.
A rights profile is a named collection of one or more authorizations, commands, and CDE actions and optional security attributes that may be assigned to the commands and actions. Rights profiles can be nested within other rights profiles.
The Rights tool in
the User Manager displays existing rights profiles
and can be used by an authorized role or user to modify
rights profiles or create new ones.
The definitions of rights profiles are stored in entries
in the prof_attr
(4) and
exec_attr
(4) databases.
A rights profile can be assigned to a user or role account in the following ways:
user_attr
(4) database.
policy.conf
(4) file.
policy.conf
file entry shown below assigns the
Basic Solaris User rights profile to everyone:
policy.conf
file, so not all users may be
able to view the same information in the SMC at all sites.
To see which profiles are available to the account entering the command or to another account, users and roles can use the profiles(1) command. To see all profiles on the system, use the list option of the smprofile(1M) command.
Authorizations are one of the means used to divide administrative responsibilities among roles. For example, the authorizations to specify security-sensitive information is assigned to the Security Administrator profile, while the authorizations to specify the same types of information that a traditional system administrator can specify is assigned to the System Administrator profile.
Authorizations are defined in the auth_attr
(4) database.
Authorizations
can be assigned system-wide
to all user and role accounts
in the policy.conf
(4) file.
For example, at a site where all users are allowed to use media devices to
save and restore data at a single label, the Security Administrator role could
assign the Allocate Device authorization
to all users with the following entry in the policy.conf
file:
AUTHS_GRANTED=Allocate Device
Top ^
Roles
A role has all the attributes of a user account--including a name,
user identification number (UID), password, home directory,
membership in a primary group and optional secondary groups,
a mailbox, a login shell, and one or more rights profiles assigned.
(Also see Attributes of User and Role Accounts.)
A role account, however, has several differences from normal user accounts that allow roles to perform their set of administrative tasks:
Users who are allowed to assume roles first log in with their own user names and passwords. The Trusted Path menu in the Front Panel displays the roles a user can assume. After choosing the Assume <rolename> Role option, the user is prompted for the role password. After role authentication is complete, an administrative workspace becomes active in which administrative work can be performed that requires the trusted path.
Top ^
Profile Shells
The profile shells execute only commands listed
in the rights profile in effect for the user or role.
A command is executed with any security attributes specified for
the command.
The profile shells,
pfsh
, pfcsh
, and pfksh
(also called "administrator's shells"),
are described on the pfexec
(1M) man page.
For normal users, the profile shells are optional. A user can either be assigned a profile shell as the account's login shell, or if a user has another login shell and access to a terminal, the user can type the name of the profile shell on the command line of a terminal.
The administrator assumes an administrative role after first logging in with a normal username and entering the password assigned to the user account. To assume the role, the administrator selects the Assume Role option from the Trusted Path menu in the front panel and then enters the role password. An administrative role workspace becomes active for the role, and all activities performed in the role workspace are part of the trusted path.
Top ^
Solaris Management Console in Trusted Solaris
In the Trusted Solaris environment, most administration
is performed by roles using either the Solaris Management Console (SMC)
or equivalent command line
interfaces.
Normal users by default do not have the needed authorizations to use
the SMC tools.
The SMC or equivalent command line interfaces require the trusted path when invoked by a role. Therefore, they can be successfully invoked by roles only in an administrative role workspace. Both the SMC and commands display the username of the logged-in user and prompt for the role password.
If the SMC or equivalent command line interface is invoked by a normal user in a normal user workspace, the user is prompted for the user password. In Trusted Solaris, users cannot assume roles through the SMC. It is possible to assign to a normal user the authorizations that are required for managing the system using the SMC. In Trusted Solaris, a user with the relevant authorizations could launch the SMC and use it in a normal user workspace without the trusted path.
One or more rights can be assigned to a user or to a role.
Top ^After becoming familiar with the predefined rights profiles, the Security Administrator may want to refine them, for example, by setting up more narrowly-defined rights profiles for specific administrators, or by creating new rights profiles. Customizing rights profiles is done through the Rights Tool in the Solaris Management Console.
Creating a New Right
From the SMC, select the Rights tool and click Action->Add Right. When the Add Right dialog box appears, follow the help instructions.
Modifying an Existing Right
From the SMC, select the Rights tool and double click the right's name in the right pane, to open the right's property dialog box. Then modify the information in the various tabs.
Top ^
Real vs Effective UID and GID
Similar to assigning the setuid and setgid to UNIX commands, you can assign a real or effective uid or gid to a command or action in a rights profile. This can enable a command or action to succeed when it requires a real or effective uid or gid that is different from the uid or gid of the account that launches the command or action.
A common use of the traditional setuid is to allow programs to run with the uid of one of the system accounts such as bin, sys, and lp to update files owned by the system account. These system accounts do not have passwords so that no one can log into these accounts and compromise the filesystem.
The following differences exist between real and effective uids in filesystem operations.
The effective group id is used by mkdir
when creating directories.
If you are not sure whether to use effective or real uids or gids, try effective first, to be consistent with the principle of least privilege. (According to the principle of least privilege, you grant only whatever extended powers are necessary and sufficient to perform a task.) If the command or action does not perform as expected, then the real ids are probably necessary.
Specify a user name in the Rights tool and the corresponding uid is used when the command or action is running. Specify a group name and the corresponding gid is used.
UID Tips and Examples
The real uid most often required is 0, the uid of root (or superuser). For example, most installation programs check that they are being run by root with real uid of 0. After assigning a real uid of root to an installation program in a rights profile, the Security Administrator can assign the rights profile to a role that has another uid, such as the System Administrator role, which usually has uid 100. When run by the role with the command in one of its rights profiles, the installation program has a uid of 0.
GID Tips and Examples
Say, for example, that your site has created a group called enghelp to allow sharing of files among the members of the enghelp group, and you want to set
up a role so that new directories created by the role are given the enghelp group. Because the group of a directory is obtained by mkdir
from the
effective gid, you then need to assign enghelp as the effective gid to mkdir
.
mkdir
in the Commands Permitted column.
mkdir
with the enghelp group id to the desired role.
mkdir
.
Any directories created by the role then have the group of enghelp.
Assigning Real or Effective IDs
From the Rights tool, double click the name of the right containing the command or action you want to change. Click the Commands or Actions tab and select the command or action. Then click Set Security Attributes. In the dialog box that opens, you can change between real and effective User and Group IDs.
Rights profiles can be nested within other rights
profiles, and more than one rights profile can be assigned to
the same user or role account.
The same command or action can occur more than once
in the rights profiles assigned to a single account and can have
different security attributes assigned.
For example, the command /usr/bin/date
may be specified in one rights profile with an effective user ID of root, but in another rights profile the
command is specified to run with privileges.
The order of the rights profiles
is important because the first occurrence of
a command or action is used with the attributes defined for
it, much the same as how the first occurrence of a command in
a user's command search path is used.
Rights profiles that assign all commands or all actions use a wildcard (*),
and because they assign no privileges or other attributes to
the commands or actions, the rights profiles that use a wildcard should
be last in the list.
Changing the Order of Rights
From the SMC, select the Rights tool and double click the name of the right you want to reorder. When the Right Properties dialog box opens, click the Supplementary Rights tab and use the Move Up and Move Down arrows on the right you select.