test

Trusted Solaris Administrator's Procedures

Privilege Enabling Mechanisms

The Trusted Solaris operating environment enables and enforces privilege inheritance by means of the system shell, profile shells, and the trusted window system.The software can also force privileges on executables with the setfpriv command. Privileged programs that require dynamically-loaded libraries search a trusted library list.

For a description of privileges themselves, see "Adding New Privileges".

System Shell

The system shell, sysh(1M), enables commands in run control (rc) scripts to execute with privilege. For every command in the rc script, the sysh consults a rights profile for security attributes. If no specific rights profile is listed for the command, the /bin/sysh shell consults the boot rights profile.

The boot and inetd rights profiles are local to each computer. They specify commands that require security attributes during booting. The boot profile specifies security attributes for commands in /etc/init.d and /etc/inittab. The inetd profile specifies security attributes for commands in /etc/inetd.conf.

Caution - Caution -

Do not assign these profiles to any user or role. The results are unpredictable.

Profile Shells

Profile shells enable users and roles to execute commands with the security attributes that make the commands work. See the pfexec(1) man page for an explanation of the three profile shells, /bin/pfsh, /bin/ksh, and /bin/sh. All roles have a profile shell as their login shell. Users may or may not be assigned a profile shell, either as a login shell or as a shell made available in a rights profile.

Profile shells do not execute commands for roles unless the commands are issued within the trusted path.

Trusted Processes in the Window System

The following window system processes are trusted:

The window system's trusted processes are available to everyone, but access to actions in the window system are restricted by an account's rights profiles. For example, the administrative actions that are in the System_Admin folder can only be used if they are in one of the account's profiles. Therefore by default, since the Check Encodings action is in the Object Label profile assigned to the Security Administrator role and the Set Mount Points action is not, the Security Administrator role can use the Check Encodings action but cannot use the Set Mount Points action.

In the File Manager, if an action is not in one of the account's profiles, the icon for the action is not visible. In the Workspace Menu, if an action is not in one of the account's profiles, the action is visible, but an error displays if the action is invoked.

The CDE window manager, dtwm(1) calls the Xtsolusersession script, which then works with the window manager to invoke actions launched from the window system. Just as the profile shell consults an account's rights profiles when the account attempts to invoke a command, Xtsolusersession also consults the account's rights profiles when the account attempts to launch an action. In either case, if the action is in an assigned rights profile, the action is run with the security attributes specified in the profile.

Trusted Libraries

Dynamically-shared libraries used by setuid, setgid, and privileged programs can be loaded only from trusted directories. The list of trusted directories is in /var/ld/ld.config. Programs that require libraries from other directories will fail. See "Making Libraries Trusted " for how to extend the list of trusted libraries.

Assigning Privileges

Privileges can be forced on an object, or can be inherited by child processes. Therefore, the Security Administrator role has two ways to assign privilege:

  1. By giving forced privileges to the executable file itself (for commands only).

  2. By assigning inheritable privileges to a command or action in a rights profile.

    When the command is executed in one of the shells that understands profiles (either the profile shells described in the pfexec(1) man page or the system shell, as described on the sysh(1M) man page, it executes with privilege. When an action is launched by a trusted process in the window system, it executes with privilege.

Giving Forced Privileges to an Executable File

The Security Administrator role can assign forced privileges to an executable file for a command by using the File Manager Privileges dialog box or by entering the setfpriv(1) command in a profile shell, as described under "To Give Forced Privileges to a Command".

When a command with forced privileges is executed by any user in any shell, the forced privileges are put into the effective set of the executing program. The only way to prevent a user from executing such a command with privilege is to control access to the command itself. If you give the user only one profile shell to use, and do not assign the command, the user cannot execute the command.

To change the privileges on an executable file, the process's label must allow MAC write access to the file. The process does not require DAC write permission. The default Security Administrator role can change the privileges on an executable file in an admin_low workspace. The forced and allowed privilege sets of a file can be changed by:

Assigning Inheritable Privileges to a Command or Action

After a site is configured, a privilege should be granted by a site's Security Administrator role only if the security administrator is convinced that the command or action will use the privilege in a trustworthy manner.

Privileges are available by inheritance when they are in a command or action's allowed privilege set. The Security Administrator role uses the Rights tool in the Solaris Management Console to specify inheritable privileges for a command or an action. The role then assigns the rights profile to a user or role, unless the profile is consulted by the system shell during boot. See "System Shell" for the profiles that are not assigned to users or roles.