Trusted Solaris User's Guide

How the Trusted Solaris environment Enables Secure Administration

In contrast to traditional UNIX systems, the superuser (root) is not all-powerful in the Trusted Solaris environment. Rather, the ability to override protections is broken into discrete capabilities and assigned to administrative roles so that no single user can compromise the system's security. A role is a special user account that gives the user access to certain applications with the authorizations, privileges, and effective UIDs/GIDs necessary for performing the specific tasks.

In the Trusted Solaris environment,

Authorizations and Privileges

There are usually cases for every security policy when a control must be overridden. In conventional UNIX systems, the superuser has the ability to override all security policy. In the Trusted Solaris environment, there is a software mechanism called an authorization that gives an individual user the right to override a specific security control. There is also a mechanism for overriding controls called a privilege that is associated with software programs and permitted for specific users only. If you are prevented from running a certain task to which you think you are entitled, check with your administrator to see if an authorization is required for that application.

Accessing Applications and Authorizations

In the Trusted Solaris environment, you get access to only those applications you need to do your job. The administrator provides access by assigning one or more execution profiles to your account. An execution profile is a special package of CDE actions, commands, and authorizations. This restriction helps prevent users from misusing applications and harming data on the system. If you need to perform tasks that override the security policy, the administrator will grant you access to either an execution profile containing the necessary authorization or to a role with the authorization to run the program.


Note -

If you have access to a special version of a command that can override security policy, you should make sure that your path is set to find this version first; otherwise, you will not be able to take advantage of the security overrides.


In addition, your administrator may assign you a profile shell as the default shell when you log in or assume a role. A profile shell is a special version of the Bourne shell that provides access to a restricted set of applications and capabilities. If you are assigned a profile shell, you can determine which commands are permitted by using the clist command at the command line. The clist command lists all commands available in the profile shell.


Note -

If you try to run an action and receive a "Not Found" error message or if you try to run a command and receive a "Not in Profile" error message, it may be a sign that you are not permitted to use this application. Check with your administrator.



Note -

If you attempt to execute a command in the profile shell, you may see the message: Warning: command operating outside of trusted path. This means that although you are working in a profile shell and the trusted symbol is being displayed, the current command is not interacting with the trusted computing base.


Predefined Roles

Trusted Solaris 8 provides five predefined roles: root, security administrator, primary administrator, system administrator, and system operator. The root role is used primarily for initial installation. The security administrator role is used for security issues, such as assigning labels or auditing user activity. The system administrator role is used to perform standard system management tasks such as setting up the non-security-relevant portions of user accounts. The system operator role is used for system backups, printer administration, and mounting removable media. The primary administrator role is used to perform any tasks requiring privileges beyond the capabilities of the other roles. If your site uses the predefined administration roles, make sure you know who is performing each set of duties.


Note -

No role can configure its own features. For example, the system administrator role is used to set up a user's access to the security administrator role and the security administrator role is used to set a user's access to the system administrator role.