This chapter describes configurable security features on a system that is configured with Solaris Trusted Extensions.
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.
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.
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 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.
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.
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.
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.
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
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 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)
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.
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.
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.
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.
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/share/gnome/sel_config file controls file relabeling actions, and the cutting and copying of information to a different label. The /usr/bin/tsoljdsselmgr 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 10–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 Selection Manager application, not by the sel_config file.
The rules for changing the label of selections are summarized in the following table.
Table 10–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.
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