Chapter 4 Security Requirements on a Trusted Extensions System (Overview)

This chapter describes configurable security features on a system that is configured with Solaris Trusted Extensions.

• Configurable Solaris Security Features

• Security Requirements Enforcement

• Rules When Changing the Level of Security for Data

• Customization of Solaris Trusted Extensions (CDE)

Configurable Solaris Security Features

Trusted Extensions uses the same security features that the Solaris OS provides, and adds some features. For example, the Solaris OS provides eeprom protection, password requirements and strong password algorithms, system protection by locking out a user, and protection from keyboard shutdown.

Trusted Extensions differs from the Solaris OS in the actual procedures that are used to modify these security defaults. In Trusted Extensions, you typically administer systems by assuming a role. Local settings are modified by using the trusted editor. Changes that affect the network of users, roles, and hosts are made in the Solaris Management Console.

Trusted Extensions Interfaces for Configuring Security Features

Procedures are provided in this book where Trusted Extensions requires a particular interface to modify security settings, and that interface is optional in the Solaris OS. Where Trusted Extensions requires the use of the trusted editor to edit local files, no separate procedures are provided in this book. For example, the procedure How to Prevent Account Locking for Users describes how to update a user's account by using the Solaris Management Console to prevent the account from being locked. However, the procedure for setting a system-wide password lock policy is not provided in this book. You follow the Solaris instructions, except that in Trusted Extensions, you use the trusted editor to modify the system file.

Extension of Solaris Security Mechanisms by Trusted Extensions

The following Solaris security mechanisms are extensible in Trusted Extensions as they are in the Solaris OS:

• Audit events and classes – Adding audit events and audit classes is described in Chapter 30, Managing Solaris Auditing (Tasks), in System Administration Guide: Security Services.

• Rights profiles – Adding rights profiles is described in Part III, Roles, Rights Profiles, and Privileges, in System Administration Guide: Security Services.

• Roles – Adding roles is described in Part III, Roles, Rights Profiles, and Privileges, in System Administration Guide: Security Services.

• Authorizations – For an example of adding a new authorization, see Customizing Device Authorizations in Trusted Extensions (Task Map).

As in the Solaris OS, privileges cannot be extended.

Trusted Extensions Security Features

Trusted Extensions provides the following unique security features:

• Labels – Subjects and objects are labeled. Processes are labeled. Zones and the network are labeled.

• Device Allocation Manager – By default, devices are protected by allocation requirements. The Device Allocation Manager GUI is the interface for administrators and for regular users.

• Change Password menu item – The Trusted Path menu enables you to change your user password, and the password of the role that you have assumed.

Security Requirements Enforcement

To ensure that the security of the system is not compromised, administrators need to protect passwords, files, and audit data. Users need to be trained to do their part. To be consistent with the requirements for an evaluated configuration, follow the guidelines in this section.

Users and Security Requirements

Each site's security administrator ensures that users are trained in security procedures. The security administrator needs to communicate the following rules to new employees and remind existing employees of these rules on a regular basis:

• Do not tell anyone your password.

  Anyone who knows your password can access the same information that you can without being identified and therefore without being accountable.

• Do not write your password down or include it in an email message.

• Choose passwords that are hard to guess.

• Do not send your password to anyone by email.

• Do not leave your computer unattended without locking the screen or logging off.

• Remember that administrators do not rely on email to send instructions to users. Do not ever follow emailed instructions from an administrator without first double-checking with the administrator.

  Be aware that sender information in email can be forged.

• Because you are responsible for the access permissions on files and directories that you create, make sure that the permissions on your files and directories are set appropriately. Do not allow unauthorized users to read a file, to change a file, to list the contents of a directory, or to add to a directory.

Your site might want to provide additional suggestions.

Email Usage

It is an unsafe practice to use email to instruct users to take an action.

Tell users not to trust email with instructions that purport to come from an administrator. Doing so prevents the possibility that spoofed email messages could be used to fool users into changing a password to a certain value or divulging the password, which could subsequently be used to log in and compromise the system.

Password Enforcement

The System Administrator role must specify a unique user name and user ID when creating a new account. When choosing the name and ID for a new account, the administrator you must ensure that both the user name and associated ID are not duplicated anywhere on the network and have not been previously used.

The Security Administrator role is responsible for specifying the original password for each account and for communicating the passwords to users of new accounts. You must consider the following information when administering passwords:

• Make sure that the accounts for users who are able to assume the Security Administrator role are configured so that the account cannot be locked. This practice ensures that at least one account can always log in and assume the Security Administrator role to reopen everyone's account if all other accounts are locked.

• Communicate the password to the user of a new account in such a way that the password cannot be eavesdropped by anyone else.

• Change an account's password if you have any suspicion that the password has been discovered by someone who should not know it.

• Never reuse user names or user IDs over the lifetime of the system.

  Ensuring that user names and user IDs are not reused prevents possible confusion about the following:

  • Which actions were performed by which user when audit records are analyzed

  • Which user owns which files when archived files are restored

Information Protection

You as an administrator are responsible for correctly setting up and maintaining discretionary access control (DAC) and mandatory access control (MAC) protections for security-critical files. Critical files include the following:

• shadow file – Contains encrypted passwords. See shadow(4).

• prof_attr database – Contains definitions of rights profiles. See prof_attr(4).

• exec_attr database – Contains commands and actions that are part of rights profiles. See exec_attr(4).

• user_attr file – Contains the rights profiles, privileges, and authorizations that are assigned to local users. See user_attr(4).

• Audit trail – Contains the audit records that the auditing service has collected. See audit.log(4)

---

Caution –

Because the protection mechanisms for LDAP entries are not subject to the access control policy enforced by the Trusted Extensions software, the default LDAP entries must not be extended, and their access rules must not be modified.

---

Password Protection

In local files, passwords are protected from viewing by DAC and from modifications by both DAC and MAC. Passwords for local accounts are maintained in the /etc/shadow file, which is readable only by superuser. For more information, see the shadow(4) man page.

Group Administration

The System Administrator role needs to verify on the local system and on the network that all groups have a unique group ID (GID).

When a local group is deleted from the system, the System Administrator role must ensure the following:

• All objects with the GID of the deleted group must be deleted or assigned to another group.

• All users who have the deleted group as their primary group must be reassigned to another primary group.

User Deletion Practices

When an account is deleted from the system, the System Administrator role and the Security Administrator role must take the following actions:

• Delete the account's home directories in every zone.

• Delete any processes or jobs that are owned by the deleted account:

  • Delete any objects that are owned by the account,or assign the ownership to another user.

  • Delete any at or batch jobs that are scheduled on behalf of the user. For details, see the at(1) and crontab(1) man pages.

• Never reuse the user (account) name or user ID.

Rules When Changing the Level of Security for Data

By default, regular users can perform cut-and-paste, copy-and-paste, and drag-and-drop operations on both files and selections. The source and target must be at the same label.

To change the label of files, or the label of information within files requires authorization. When users are authorized to change the security level of data, the Selection Manager application mediates the transfer. The /usr/dt/config/sel_config file controls file relabeling actions, and the cutting and copying of information to a different label. The /usr/dt/bin/sel_mgr application controls drag-and-drop operations between windows. As the following tables illustrate, the relabeling of a selection is more restrictive than the relabeling of a file.

The following table summarizes the rules for file relabeling. The rules cover cut-and-paste, copy-and-paste, and drag-and-drop operations.

Table 4–1 Conditions for Moving Files to a New Label

Transaction Description	Label Relationship	Owner Relationship	Required Authorization
Copy and paste, cut and paste, or drag and drop of files between File Managers	Same label	Same UID	None
	Downgrade	Same UID	solaris.label.file.downgrade
	Upgrade	Same UID	solaris.label.file.upgrade
	Downgrade	Different UIDs	solaris.label.file.downgrade
	Upgrade	Different UIDs	solaris.label.file.upgrade

Different rules apply to selections within a window or file. Drag-and-drop of selections always requires equality of labels and ownership. Drag-and-drop between windows is mediated by the sel_mgr application, not by the sel_config file.

The rules for changing the label of selections are summarized in the following table.

Table 4–2 Conditions for Moving Selections to a New Label

Transaction Description	Label Relationship	Owner Relationship	Required Authorization
Copy and paste, or cut and paste of selections between windows	Same label	Same UID	None
	Downgrade	Same UID	solaris.label.win.downgrade
	Upgrade	Same UID	solaris.label.win.upgrade
	Downgrade	Different UIDs	solaris.label.win.downgrade
	Upgrade	Different UIDs	solaris.label.win.upgrade
Drag and drop of selections between windows	Same label	Same UID	None applicable

Trusted Extensions provides a selection confirmer to mediate label changes. This window appears when an authorized user attempts to change the label of a file or selection. The user has 120 seconds to confirm the operation. To change the security level of data without this window requires the solaris.label.win.noview authorization, in addition to the relabeling authorizations. The following illustration shows a selection, zonename, in the window.

By default, the selection confirmer displays whenever data is being transferred to a different label. If a selection requires several transfer decisions, the automatic reply mechanism provides a way to reply once to the several transfers. For more information, see the sel_config(4) man page and the following section.

sel_config File

The sel_config file is checked to determine the behavior of the selection confirmer when an operation would upgrade or downgrade a label.

The sel_config file defines the following:

• A list of selection types to which automatic replies are given

• Whether certain types of operations can be automatically confirmed

• Whether a selection confirmer dialog box is displayed

In Trusted CDE, the Security Administrator role can change the defaults by using the Configure Selection Confirmation action in the Trusted_Extensions folder. The new settings become effective at the next login. If you are in Solaris Trusted Extensions (JDS) when modifying the file, do not use the CDE action. Copy the sel_config file to the /etc/dt/config directory. Then, customize that copy as you would customize any other CDE configuration file.

Customization of Solaris Trusted Extensions (CDE)

In Solaris Trusted Extensions (CDE), users can add actions to the Front Panel and customize the Workspace menu. Trusted Extensions software limits users' ability to add programs and commands to CDE.

Front Panel Customization

Anyone can drag and drop a pre-existing action from the Application Manager to the Front Panel, as long as the account performing the modification has the action in its profile. Actions in the /usr/dt/ or /etc/dt/ directories can be added to the Front Panel, but applications in the $HOME/.dt/appconfig directory cannot. While users can use the Create Action action, they cannot write into any of the directories where the system-wide actions are stored. Therefore, regular users cannot create actions that are usable.

In Trusted Extensions, the actions' search path has been changed. Actions in any individual's home directory are processed last instead of first. Therefore, no one can customize existing actions.

The Security Administrator role is assigned the Admin Editor action, so can make any needed modifications to the /usr/dt/appconfig/types/C/dtwm.fp file and the other configuration files for the Front Panel subpanels.

Workspace Menu Customization

The Workspace Menu is the menu that appears when you click mouse button 3 on the background of the workspace. Regular users can customize the menu, and add items to the menu.

The following conditions apply when a user is allowed to work at multiple labels:

• The user must have a home directory in the global zone.

  To save the customizations, processes in the global zone must be able to write to the user's home directory at the correct label. The zone path to a user home directory that is writable by global zone processes is similar to the following:

  /zone/zone-name/home/username

• The user must use the Customize Menu and Add Item to Menu options in a regular user workspace. The user can create a different customization for each label.

• When the user assumes a role, changes to the Workspace Menu persist.

• Changes that are made to the Workspace Menu are stored in the user's home directory at the current label. The customized menu file is .dt/wsmenu.

• The user's rights profile must enable the user to run the desired action.

  Any action that is added to the Workspace Menu must be handled by one of the user's rights profiles. Otherwise, the action fails when invoked and an error message is displayed.

  For example, anyone with the Run action can double-click the icon for any executable and run it, even if the action or any commands that the action invokes are not in one of the account's rights profiles. By default, roles are not assigned the Run action. Therefore, any menu item that requires the Run action fails when executed by a role.