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.