Go to main content

Trusted Extensions Configuration and Administration

Exit Print View

Updated: November 2020

Security Attributes That Must Be Assigned to Users

The security administrator can modify the security attributes for new users. For information about the files that contain the default values, see Default User Security Attributes in Trusted Extensions. The following table shows the security attributes that can be assigned to users and the effect of each assignment.

Note -  If you are using the account-policy SMF stencil and the group property for a security attribute is enabled, then security policy is determined by the SMF property. The value in /etc/security/policy.conf file is not used. For examples of viewing and changing account-policy properties, see the procedures in Modifying Rights System-Wide As SMF Properties in Securing Users and Processes in Oracle Solaris 11.4. See also the account-policy(8S) man page.

The label_encodings file is not affected by the account-policy service, nor are audit flags.

Table 14  Security Attributes That Are Assigned After User Creation
User Attribute
Location of Default Value
Is Action Required
Effect of Assignment
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
User is audited differently from the system defaults

Security Attribute Assignment to Users in Trusted Extensions

The security administrator assigns security attributes to users 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, consider the following information:

Assigning Passwords

The system administrator can assign passwords to user accounts during account creation. After this initial assignment, the security administrator or the user can change the password.

Your password change policy should follow industry standards. System administration logins, such as root, must be carefully controlled. Administration should be through roles, users with rights profiles, or sudo. These administrative methods use least privilege and write administrative events to the audit trail. For password attributes that Oracle Solaris can enforce when a password is changed, 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 user can be assigned more than one role if doing so is consistent with your site's security policy.

Assigning Authorizations

As in the Oracle Solaris OS, assigning authorizations to a user adds those authorizations to existing authorizations. For scalability, add the authorizations to a rights profile, then assign the profile to the user.

Assigning Rights Profiles

As in the Oracle Solaris OS, the order of rights profiles is important. With the exception of authorizations, the profile mechanism uses the value of the first instance of an assigned security attribute. For more information, see Order of Search for Assigned Rights in Securing Users and Processes in Oracle Solaris 11.4.

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 rights profile cannot 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 or the SMF property if you have enabled the account-policy service. To change the privilege set for individual users, 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 Oracle Solaris OS, assigning audit classes to a user modifies the user's preselection mask. For more information about auditing, see Managing Auditing in Oracle Solaris 11.4.

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

  • .aliases
  • .bashrc
  • .bashrc.user
  • .emacs
  • .login
  • .mailrc
  • .mime_types
  • .signature