Trusted Solaris Administrator's Procedures

Testing New Software for Security

The default Trusted Solaris programs and actions have already been assigned privileges, effective UIDs or effective GIDs when any of these attributes are required for the programs or actions to do their work. This section outlines the issues and tasks associated with adding the following types of software:

Sun software products and third-party applications that neither understand nor enforce Trusted Solaris security policy
New programs, created using Trusted Solaris programming interfaces, that understand labels and MAC (mandatory access control) and that work within Trusted Solaris security policy
New actions (created or approved by the Security Administrator role)
Shell scripts (created or approved by the Security Administrator role)

Some programs run at a single level with no privileges required, so the Security Administrator role can simply install them at ADMIN_LOW in a public directory and assign them as desired as commands in the rights profiles of users and roles without assigning privileges or modifying any other attributes to make the programs work. Other programs that need to bypass security policy may need to be assigned privileges. The person who assesses the program needs to understand security and thoroughly understand what the new program is trying to accomplish.

Evaluating a Program for Security

The security administrator is responsible for testing and evaluating new software. When your site wants to add any existing programs to a Trusted Solaris environment, whether it is an application written outside of your organization, a Solaris software program, or a program written in house, the security administrator makes the final determination. Part of the determination is technical, and part is affected by site policy and procedures.

Find out if the application runs without changes in the Trusted Solaris environment.

If it runs without privilege or any modification, the System Administrator role can install the application.
If the program fails to run, find out why.

Some software packages and third-party applications written for the Solaris environment cannot run because of certain modifications made to the Trusted Solaris operating environment to enforce security policy. For example, software that links with the kernel may be incompatible with Trusted Solaris modified kernel data structures. For similar reasons, loadable device drivers and other software may not be capable of operating in the environment unless changes are made to the code.

If the program does not rely on aspects of the Solaris operating environment that have been modified for the Trusted Solaris environment, but it fails without privileges, find out what privileges or other attributes it needs.
If the program does require the use of privilege, assess whether the program will use its privileges in a trustworthy manner. See "Considering When to Add Privilege".

If the program cannot use its privileges in a trustworthy manner and it cannot be modified, do not make it available.
If the program can safely run with the privileges or other security attributes in a manner that does not violate security policy, you may then assign the required privileges as described in "Assigning Inheritable Privileges to a Command or Action".

If you make privileges available to a program, you need to make sure that any libraries used by the program are identified as trusted. See "Making Libraries Trusted ".
If you can modify the program's source code, a security consultant or programmer knowledgeable about security can modify the code.

These modifications might include privilege bracketing or adding code that makes the program aware of the Trusted Solaris security policy. You may then add privileges and trusted libraries. See "Making Libraries Trusted ".

Considering When to Add Privilege

The most obvious type of program that fails without privileges is one that needs to run in the Solaris environment as root (such as a program that executes with setuid root). This kind of program can be assigned an effective UID of root in a rights profile that is assigned to an administrative role.

UNIX applications that need to violate DAC often are implemented to make careful checks before doing so on a user's behalf. However, most applications are written in environments that do not have Trusted Solaris security mechanisms such as MAC. Therefore, a standard UNIX application does not carefully check MAC before violating MAC on a user's behalf. An administrator who gives such a program a MAC-override privilege may unintentionally provide a way for users to override MAC arbitrarily.

Some of the security considerations to be assessed are illustrated by the behavior of rcp(1), which is a commonly used UNIX program. The rcp command, which copies files across a network, runs with setuid root. Running as root allows the program to run with all privileges in a standard UNIX system. Although the program is allowed to bypass DAC restrictions, it checks for DAC permissions on a file to make sure the user who executed the has permission to access the file. But rcp has no knowledge of MAC restrictions. If you gave the rcp command the file_mac_read or file_mac_write privilege, it would not do the right kinds of checks for MAC relationships when accessing a file for a user; so rcp would not be able to use the privileges you assigned it in a manner that enforces the security policy of the system.

If you simply assign a similar program the privileges it needs to run and do not modify it to work within the security policy of the Trusted Solaris environment, the program violates system security. In order to make it run without violating system security, you would need to add to the program's source code. For example, if a program needed to bypass MAC restrictions when reading and writing files, you would need to modify the source code by adding the necessary MAC checks.

Some software may need privileges for reasons that are not obvious and sometimes not necessary for the program to succeed. Even if it is not performing any function that seems to violate system security policy, an application may be doing something internally that does violate security, such as keeping track of its operations in a shared log file, or reading from /dev/kmem (see mem(7D)). Sometimes these internal policy overrides are not particularly important to the application's correct operation but merely provide a convenient feature for users. If your organization has access to the source code, check if you can remove the operations that require policy overrides without affecting the performance of the application.

If the program would violate aspects of Trusted Solaris security policy, such as reading and writing files without doing MAC checks, then you should probably either make sure the required MAC checks are added to the source code, if you can, or not port the program.

Running a Program As Root

When an application has been written to run as root, the Security Administrator role has three options (all of which should be assessed for consistency with the site's security policy):

If a real UID of root is not required, set up the application to run with an effective UID of root.
Otherwise, set it up with a real UID of root.
Find out what privileges the application needs and assign only the needed privileges, after determining that the application can use the privileges in a trustworthy manner.

Cooperating to Create a Trusted Program

Even though a program's developer can manipulate privilege sets in the program's source code, if the Security Administrator role does not assign the required privileges, the program will fail. The developer and security administrator cooperate when creating trusted programs.

Developer's Responsibilities

A developer who writes a program to be added to a Trusted Solaris environment must do the following:

Understand whether the program requires privileges to do its work.
Know and follow techniques, such as privilege bracketing, for safely using privileges in programs.
Be aware of the security implications when assigning privileges to a program and make sure that the program does not violate security policy.
Compile using shared libraries linked to the program from a trusted directory.

See the Trusted Solaris Developer's Guide for additional guidelines and examples of using privileges in programs.

Security Administrator Role`s Responsibilities

The Security Administrator role must ensure that a program that uses Trusted Solaris system calls and routines not compromise the security of the Trusted Solaris environment in any way.

Make sure the programmer and the program distribution process is trusted.
From one of these sources, find out which privileges are required by the program:
1. Ask the programmer.
2. Search the source code for any privileges that the program expects to use.
3. Use the runpd command as described in "To Find Out Which Privileges a Program Needs".
Scrutinize the source code to make sure it behaves in a trustworthy manner when using the privileges it needs to operate.

Adding Trusted Actions

The process of creating and using actions is pretty much the same in the Trusted Solaris environment as it is in a Solaris environment. Adding actions is described in the "Adding and Administering Applications" in Solaris Common Desktop Environment: Advanced User's and System Administrator's Guide.

In the Trusted Solaris environment, use of actions is controlled by the rights profile mechanism. Actions that are assigned security attributes in a rights profile can run with the assigned security attributes if they are invoked within one of the window system's trusted processes. In the Trusted Solaris environment, a number of actions have been assigned security attributes in the rights profiles of administrative roles. The Security Administrator role can also use the Rights tool to assign security attributes to new actions.

The following table summarizes the main differences encountered in creating and using actions in the Trusted Solaris environment.

Table 13-1 Constraints on Actions in the Trusted Solaris Environment


Solaris CDE	Trusted Solaris CDE
New actions may be created by anyone within the originator's home directory, and a new action is automatically usable by its creator.	An action is only usable by a user or role if the action is one of the account's rights profiles. The actions' search path has been changed so that actions in any individual's home directory are processed last instead of first. Therefore, no one can customize existing actions.
	If either the Create Action action or commands or actions that permit the editing of files are in an account's profile, the user or role can create a new action in the account's home directory, but the account may not be able to use the new action.
	There are two ways a user can use a new action: if the Security Administrator role adds the name of the new action to one of the account's rights profiles, or if the user has the All profile. The All profile turns off all checks for actions, and as a result any existing and potential actions may then be used by that account.
	If the account is allowed to use the action by its rights profiles, the account can launch the action from its home directory through the File Manager. The default System Administrator and administrator roles are permitted to place actions in public directories.
Actions can be dragged and dropped to the Front Panel.	The Front Panel is part of the trusted path. The window manager recognizes only the administratively-added actions that are located in `/usr/dt` and `/etc/dt` subdirectories where system-wide action files are kept. Even if a normal user account or a non-administrative role account creates a new action in the account's home directory and has the All Accounts profile, new actions dragged to the Front Panel from the user's home directory are not recognized by the window manager, which only looks in the public directories.
The only way that actions can do privileged operations is if they are run by root.	If actions are specified to have privileges in one of the invoking account's rights profiles, actions can inherit privileges when they are launched from a trusted process. Therefore, the only way that actions can do privileged operation is if they have been assigned privileges in the account's profiles.
Actions are not managed by the Solaris Management Console.	Actions are assigned to rights profiles by the Rights tool. If new actions are added, the Security Administrator role needs to make the new actions available. See "To Make New Actions Available to the Rights Tool".