Any software that can be added to an Oracle Solaris system can be added to a system that is configured with Trusted Extensions. Additionally, programs that use Trusted Extensions APIs can be added. Adding software to a Trusted Extensions system is similar to adding software to an Oracle Solaris system that is running non-global zones.
In Trusted Extensions, programs are typically installed in the global zone for use by regular users in labeled zones. However, you can install packages in a labeled zone by running the pkg command in the zone. If you do so, you must ensure that the zone can handle administrative accounts and password prompts. For a discussion, see Applications That Are Restricted to a Labeled Zone. For details about packages and zones, see Chapter 8, About Automatic Installation and Packages on an Oracle Solaris System With Zones Installed in Creating and Using Oracle Solaris Zones.
At a Trusted Extensions site, the system administrator and the security administrator work together to install software. The security administrator evaluates software additions for adherence to security policy. When the software requires privileges or authorizations to succeed, the Security Administrator role assigns an appropriate rights profile to the users of that software.
To import software from removable media requires authorization. An account with the Allocate Device authorization can import or export data from removable media. Data can include executable code. A regular user can only import data at a label within that user's clearance.
The System Administrator role is responsible for adding the programs that the security administrator approves.
Trusted Extensions uses the same security mechanisms as Oracle Solaris. The mechanisms include the following:
Authorizations – Users of a program can be required to have a particular authorization. For information about authorizations, see Basics of User and Process Rights in Securing Users and Processes in Oracle Solaris 11.3. Also, see the auth_attr(4) man page.
Privileges – Programs and processes can be assigned privileges. For information about privileges, see Chapter 1, About Using Rights to Control Users and Processes in Securing Users and Processes in Oracle Solaris 11.3. Also, see the privileges(5) man page.
The ppriv command provides a debugging utility. For details, see the ppriv(1) man page. For instructions on using this utility with programs that work in non-global zones, see Privileges in a Non-Global Zone in Creating and Using Oracle Solaris Zones.
Right Profiles – Rights profiles collect security attributes in one place for assignment to users or roles. For information about rights profiles, see More About Rights Profiles in Securing Users and Processes in Oracle Solaris 11.3.
Trusted libraries – Dynamically shared libraries that are used by setuid, setgid, and privileged programs can be loaded only from trusted directories. As in Oracle Solaris, the crle command is used to add a privileged program's shared library directories to the list of trusted directories. For details, see the crle(1) man page.
When software has been assigned privileges or when it runs with an alternate user ID or group ID, the software becomes trusted. Trusted software can bypass aspects of the Trusted Extensions security policy. Be aware that you can make software trusted even though it might not be worthy of trust. The security administrator must wait to give privileges to software until careful scrutiny has revealed that the software uses the privileges in a trustworthy manner.
Programs fall into three categories on a trusted system:
Programs that require no security attributes – Some programs run at a single level and require no privileges. These programs can be installed in a public directory, such as /usr/local. For access, assign the programs as commands in the rights profiles of users and roles.
Programs that run as root – Some programs execute with setuid 0. Such programs can be assigned an effective UID of 0 in a rights profile. The security administrator then assigns the profile to an administrative role.
Programs that require privileges – Some programs might need privileges for reasons that are not obvious. Even if a program is not performing any function that seems to violate system security policy, the program might be doing something internally that violates security. For example, the program could be using a shared log file, or the program could be reading from /dev/kmem. For security concerns, see the mem(7D) man page.
Sometimes, an internal policy override is not particularly important to the application's correct operation. Rather, the override provides 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 application's performance.
Even though a program's developer can manipulate privilege sets in the source code, if the security administrator does not assign the required privileges to the program, the program will fail. The developer and security administrator need to cooperate when creating trusted programs.
Understand where 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. The program must not violate security policy.
Compile the program by using shared libraries that are linked to the program from a trusted directory.
The security administrator is responsible for testing and evaluating new software. After determining that the software is trustworthy, the security administrator configures rights profiles and other security-relevant attributes for the program.
The security administrator responsibilities include the following:
Make sure that the programmer and the program distribution process is trusted.
From one of the following sources, determine which privileges are required by the program:
Ask the programmer.
Search the source code for any privileges that the program expects to use.
Search the source code for any authorizations that the program requires of its users.
Use the debugging options to the ppriv command to search for use of privilege. For examples, see the ppriv(1) man page. You can also use dtrace to evaluate privilege and authorization use.
Examine the source code to make sure that the code behaves in a trustworthy manner regarding the privileges that the program needs to operate.
If the program fails to use privilege in a trustworthy manner, and you can modify the program's source code, then modify the code. A security consultant or developer who is knowledgeable about security can modify the code. Modifications might include privilege bracketing or checking for authorizations.
The assignment of privileges must be manual. A program that fails due to lack of privilege can be assigned privileges. Alternatively, the security administrator might decide to assign an effective UID or GID to make the privilege unnecessary.
Create and assign rights profiles for the new program.