Chapter 19 Software Management in Trusted Extensions (Tasks)

This chapter contains information about ensuring that third-party software runs in a trustworthy manner on a system that is configured with Solaris Trusted Extensions.

• Adding Software to Trusted Extensions

• Trusted Processes in the Window System

• Managing Software in Trusted Extensions (Tasks)

Adding Software to Trusted Extensions

Any software that can be added to a 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 a Solaris system that is running non-global zones.

For example, packaging issues affect systems that have installed non-global zones. Package parameters define the following:

• The zone scope of the package – The scope determines the type of zone in which a specific package can be installed.

• The visibility of the package – Visibility determines whether a package must be installed and be identical in all zones.

• The limitation of the package – One limitation is whether a package must be installed in the current zone only.

In Trusted Extensions, programs are typically installed in the global zone for use by regular users in labeled zones. For details about installing packages in zones, see Chapter 24, About Packages and Patches on a Solaris System With Zones Installed (Overview), in System Administration Guide: Virtualization Using the Solaris Operating System. Also, see the pkgadd(1M) man page.

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.

Solaris Security Mechanisms for Software

Trusted Extensions uses the same security mechanisms as the Solaris OS. The mechanisms include the following:

• Authorizations – Users of a program can be required to have a particular authorization. For information about authorizations, see Solaris RBAC Elements and Basic Concepts in System Administration Guide: Security Services. Also, see the auth_attr(4) and getauthattr(3SECDB) man pages.

• Privileges – Programs and processes can be assigned privileges. For information about privileges, see Chapter 8, Using Roles and Privileges (Overview), in System Administration Guide: Security Services. 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 Using the ppriv Utility in System Administration Guide: Virtualization Using the Solaris Operating System.

• Right Profiles – Rights profiles collect security attributes in one place for assignment to users or roles. For information about rights profiles, see RBAC Rights Profiles in System Administration Guide: Security Services. Trusted Extensions adds CDE actions to the type of executables that can be assigned security attributes.

• Trusted libraries – Dynamically shared libraries that are used by setuid, setgid, and privileged programs can be loaded only from trusted directories. As in the Solaris OS, 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.

Evaluating Software for Security

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.

  ---

  Tip –

  If the application can use privileges in a trustworthy manner, assign the needed privileges to the application, and do not execute the program as root.

  ---

• 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.

Developer Responsibilities When Creating Trusted Programs

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.

A developer who writes a trusted program must do the following:

1. Understand where the program requires privileges to do its work.

2. Know and follow techniques, such as privilege bracketing, for safely using privileges in programs.

3. Be aware of the security implications when assigning privileges to a program. The program must not violate security policy.

4. Compile the program by using shared libraries that are linked to the program from a trusted directory.

   For additional information, see Solaris Security for Developers Guide. For examples of code for Trusted Extensions, see Solaris Trusted Extensions Developer’s Guide.

Security Administrator Responsibilities for Trusted Programs

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:

1. Make sure that the programmer and the program distribution process is trusted.

2. 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.

3. 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.

Trusted Processes in the Window System

In Solaris Trusted Extensions (CDE), the following window system processes are trusted:

• Front Panel

• Subpanels of the Front Panel

• Workspace Menu

• File Manager

• Application Manager

The window system's trusted processes are available to everyone, but access to administrative actions is restricted to roles in the global zone.

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.

In Trusted CDE, the window manager, dtwm, calls the Xtsolusersession script. This script works with the window manager to invoke actions that are started from the window system. The Xtsolusersession script checks 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 that are specified in the profile.

Adding Trusted CDE Actions

The process of creating and using CDE actions in Trusted Extensions is similar to the process in the Solaris OS. Adding actions is described in the Chapter 4, Adding and Administering Applications, in Solaris Common Desktop Environment: Advanced User’s and System Administrator’s Guide.

As in the Solaris OS, the use of actions can be controlled by the rights profile mechanism. In Trusted Extensions, several actions have been assigned security attributes in the rights profiles of administrative roles. The security administrator can also use the Rights tool to assign security attributes to new actions.

The following table summarizes the main differences between a Solaris system and a Solaris Trusted Extensions system when you create and use actions.

Table 19–1 Constraints on CDE Actions in Trusted Extensions

Solaris CDE Actions	Trusted CDE Actions
New actions can be created by anyone within the originator's home directory. A new action is automatically usable by its creator.	An action is usable only if the action is in a rights profile that is assigned to the user. The search path for actions differs. Actions in a user's home directory are processed last instead of first. Therefore, no one can customize existing actions.
	Users can create a new action in their home directory, but the action might not be usable.
	Users with the All profile can use an action that they create. Otherwise, the security administrator must add the name of the new action to one of the account's rights profiles.
	To start the action, the user uses the File Manager. The system administrator can 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 the /usr/dt and /etc/dt subdirectories. Even with the All profile, a user cannot drag a new action to the Front Panel. Actions from a user's home directory are not recognized by the window manager. The manager only checks the public directories.
Actions can do privileged operations if they are run by root.	Actions can do privileged operations if the actions have been assigned privileges in a rights profile that has been assigned to a user.
Actions are not managed by the Solaris Management Console.	Actions are assigned to rights profiles in the Rights tool of the Solaris Management Console. If new actions are added, the security administrator can make the new actions available.

Managing Software in Trusted Extensions (Tasks)

Managing software in Trusted Extensions is similar to managing software on a Solaris system that has installed non-global zones. For details about zones, see Part II, Zones, in System Administration Guide: Virtualization Using the Solaris Operating System.

How to Add a Software Package in Trusted Extensions

Before You Begin

You must be in a role that can allocate a device.

1. Start from the appropriate workspace.

   • To install a software package in the global zone, stay in the global zone.

   • To install a software package in a labeled zone, create a workspace at that label.

     For details, see How to Change the Label of a Workspace in Solaris Trusted Extensions User’s Guide.

2. Allocate the CD-ROM drive.

   For details, see How to Allocate a Device in Trusted Extensions in Solaris Trusted Extensions User’s Guide.

3. Install the software.

   For details, see Where to Find Software Management Tasks in System Administration Guide: Basic Administration.

4. Deallocate the device when you are finished.

   For details, see How to Allocate a Device in Trusted Extensions in Solaris Trusted Extensions User’s Guide.

How to Install a Java Archive File in Trusted Extensions

This procedure downloads a Java^TM archive (JAR) file to the global zone. From the global zone, the administrator can make it available to regular users.

Before You Begin

The security administrator has verified that the source of the Java program is trustworthy, that the method of delivery is secure, and that the program can run in a trustworthy manner.

You are in the System Administrator role in the global zone. The Software Installation rights profile includes the Open action for Java code.

1. Download the JAR file to the /tmp directory.

   For example, if you are selecting software from http://www.sunfreeware.com, use the site's Web Start Wizard Installation of Freeware instructions.

2. Open the File Manager and navigate to the /tmp directory.

3. Double-click the downloaded file.

4. To install the software, answer the questions in the dialog boxes.

5. Read the installation log.

---

Example 19–1 Downloading a JAR File to a User Label

To limit the security risk, the system administrator downloads the software to a single label within a regular user's accreditation range. Then, the security administrator tests the JAR file at that label. When the software passes the test, the security administrator then downgrades the label to ADMIN_LOW. The system administrator installs the software on an NFS server to make it available to all users.

1. First, the system administrator creates a workspace at a user label.

2. In that workspace, he downloads the JAR file.

3. At that label, the security administrator tests the file.

4. Then, the security administrator changes the label of the file to ADMIN_LOW.

5. Finally, the system administrator copies the file to an NFS server whose label is ADMIN_LOW.

---