Solaris Trusted Extensions Administrator's Procedures

Chapter 12 Users, Rights, and Roles in Trusted Extensions (Overview)

This chapter describes essential decisions that you must make before creating regular users, and provides additional background information for managing user accounts. The chapter assumes that the initial setup team has set up roles and a limited number of user accounts. These users can assume the roles that are used to configure and administer Solaris Trusted Extensions. For details, see Creating Roles and Users in Trusted Extensions.

User Security Features in Trusted Extensions

Trusted Extensions software adds the following security features to users, roles, or rights profiles:

Administrator Responsibilities for Users

The System Administrator role creates user accounts. The Security Administrator role sets up the security aspects of an account.

If you are using the Sun JavaTM System Directory Server for the LDAP naming service, check that the initial setup team configured the tsol_ldap.tbx toolbox. For the procedure, see Configuring the Solaris Management Console for LDAP (Task Map).

For details on setting up users and roles, see the following:

System Administrator Responsibilities for Users

In Trusted Extensions, the System Administrator role is responsible for determining who can access the system. The system administrator is responsible for the following tasks:

Security Administrator Responsibilities for Users

In Trusted Extensions, the Security Administrator role is responsible for all security attributes of a user or role. The security administrator is responsible for the following tasks:

Typically, the Security Administrator role creates rights profiles. However, if a profile needs capabilities that the Security Administrator role cannot grant, then superuser or the Primary Administrator role can create the profile.

Before creating a rights profile, the security administrator needs to analyze whether any of the commands in the new profile need privilege or authorization to be successful. The man pages for individual commands list the privileges and authorizations that might be needed.

Decisions to Make Before Creating Users in Trusted Extensions

The following decisions affect what users are able to do in Trusted Extensions and how much effort is required. Some decisions are the same as the decisions that you would make when installing the Solaris OS. However, decisions that are specific to Trusted Extensions can affect site security and ease of use.

Default User Security Attributes in Trusted Extensions

Settings in the label_encodings and the policy.conf files together define default security attributes for user accounts. The values that you explicitly set for a user override these system values. Some values that are set in these files also apply to role accounts. For security attributes that you can explicitly set, see Configurable User Attributes in Trusted Extensions.

label_encodings File Defaults

The label_encodings file defines a user's minimum label, clearance, and default label view. For details about the file, see the label_encodings(4) man page. Your site's label_encodings file was installed by your initial setup team. Their decisions were based on Devising a Label Strategy, and examples from Solaris Trusted Extensions Label Administration.

Label values that the security administrator explicitly sets for individual users in the Solaris Management Console are derived from the label_encodings file. Explicitly set values override the values in the label_encodings file.

policy.conf File Defaults in Trusted Extensions

The Solaris /etc/security/policy.conf file contains the default security settings for the system. Trusted Extensions adds two keywords to this file. You can add these keyword=value pairs to the file if you want to change the system-wide value. These keywords are enforced by Trusted Extensions.

Table 12–1 Trusted Extensions Security Defaults in policy.conf File


Default Value 

Possible Values 





Does not apply to roles. 



0 to 120 minutes 

Does not apply to roles. 

The authorizations and rights profiles that are defined in the policy.conf file are in addition to any authorizations and profiles that are assigned to individual accounts. For the other fields, the individual user's value overrides the system value.

Planning User Security in Trusted Extensions includes a table of every policy.conf keyword. See also the policy.conf(4) man page.

Configurable User Attributes in Trusted Extensions

The Solaris Management Console 2.1 is your tool for creating and modifying user accounts. For users who can log in at more than one label, you might also want to set up .copy_files and .link_files files in each user's minimum–label home directory.

The User Accounts tool in the Solaris Management Console works as it does in the Solaris OS, with two exceptions:

As described in How to Add a User With the Solaris Management Console’s Users Tool in System Administration Guide: Basic Administration, a wizard enables you to create user accounts quickly. After using the wizard, you can modify the user's default Trusted Extensions attributes.

For more information about the .copy_files and .link_files files, see .copy_files and .link_files Files.

Security Attributes That Must Be Assigned to Users

The Security Administrator role must specify some security attributes for new users, as the following table shows. For information about the files that contain default values, see Default User Security Attributes in Trusted Extensions.

Table 12–2 Security Attributes That Are Assigned After User Creation

User Attribute 

Location of Default Value 

Is Action Required 

Effect of Action 




User has password 




User can assume a role 


policy.conf file


User has additional authorizations 

Rights Profiles 

policy.conf file


User has additional rights profiles 


label_encodings file


User has different default label or accreditation range 


policy.conf file


User has different set of privileges 

Account Usage 

policy.conf file


User has different setting for computer when it is idle 


audit_control file


User is audited differently from the system audit settings 

Security Attribute Assignment to Users in Trusted Extensions

The Security Administrator role assigns security attributes to users in the Solaris Management Console after the user accounts are created. If you have set up correct defaults, your next step is to assign security attributes only for users who need exceptions to the defaults.

When assigning security attributes to users, the security administrator considers the following information:

Assigning Passwords

The Security Administrator role assigns passwords to user accounts after the accounts have been created. After this initial assignment, users can change their passwords.

As in the Solaris OS, users can be forced to change their passwords at regular intervals. The password aging options limit how long any intruder who is able to guess or steal a password could potentially access the system. Also, establishing a minimum length of time to elapse before changing a password prevents a user with a new password from reverting immediately to the old password. For details, see the passwd(1) man page.

Note –

The passwords for users who can assume roles must not be subject to any password aging constraints.

Assigning Roles

A user is not required to have a role. A single user can be assigned more than one role if doing so is consistent with your site's security policy.

Assigning Authorizations

As in the Solaris OS, assigning authorizations directly to a user adds those authorizations to existing authorizations. In Trusted Extensions, you add the authorizations to a rights profile, then assign the profile to the user.

Assigning Rights Profiles

As in the Solaris OS, the order of profiles is important. The profile mechanism uses the first instance of the command in an account's profile set.

You can use the sorting order of profiles to your advantage. If you want a command to run with different security attributes from those attributes that are defined for the command in an existing profile, create a new profile with the preferred assignments for the command. Then, insert that new profile before the existing profile.

Note –

Do not assign rights profiles that include administrative commands to a regular user. The profile would not work because a regular user cannot enter the global zone.

Changing Privilege Default

The default privilege set can be too liberal for many sites. To restrict the privilege set for any regular user on a system, change the policy.conf file setting. To change the privilege set for individual users, use the Solaris Management Console. For an example, see How to Restrict a User's Set of Privileges.

Changing Label Defaults

Changing a user's label defaults creates an exception to the user defaults in the label_encodings file.

Changing Audit Defaults

As in the Solaris OS, assigning audit classes to a user creates exceptions to the audit classes that are assigned in the /etc/security/audit_control file on the system. For more information about auditing, see Chapter 24, Trusted Extensions Auditing (Overview).

.copy_files and .link_files Files

In Trusted Extensions, files are automatically copied from the skeleton directory only into the zone that contains the account's minimum label. To ensure that zones at higher labels can use startup files, either the user or the administrator must create the files .copy_files and .link_files.

The Trusted Extensions files .copy_files and .link_files help to automate the copying or linking of startup files into every label of an account's home directory. Whenever a user creates a workspace at a new label, the updatehome command reads the contents of .copy_files and .link_files at the account's minimum label. The command then copies or links every listed file into the higher-labeled workspace.

The .copy_files file is useful when a user wants a slightly different startup file at different labels. Copying is preferred, for example, when users use different mail aliases at different labels. The .link-files file is useful when a startup file should be identical at any label that it is invoked. Linking is preferred, for example, when one printer is used for all labeled print jobs. For example files, see How to Configure Startup Files for Users in Trusted Extensions.

The following lists some startup files that you might want users to be able to link to higher labels or to copy to higher labels: