Skip Navigation Links | |
Exit Print View | |
Solaris Trusted Extensions Installation and Configuration for Solaris 10 11/06 and Solaris 10 8/07 Releases |
1. Security Planning for Trusted Extensions
2. Installation and Configuration Roadmap for Trusted Extensions
3. Installing Solaris Trusted Extensions Software (Tasks)
4. Configuring Trusted Extensions (Tasks)
Setting Up the Global Zone in Trusted Extensions
Check and Install Your Label Encodings File
Enable IPv6 Networking in Trusted Extensions
Create ZFS Pool for Cloning Zones
Reboot and Log In to Trusted Extensions
Initialize the Solaris Management Console Server in Trusted Extensions
Make the Global Zone an LDAP Client in Trusted Extensions
Configure the Network Interfaces in Trusted Extensions
Create Another Zone in Trusted Extensions
Add a Network Interface to an Existing Labeled Zone
Creating Roles and Users in Trusted Extensions
Create the Security Administrator Role in Trusted Extensions
Create Users Who Can Assume Roles in Trusted Extensions
Creating Home Directories in Trusted Extensions
Create the Home Directory Server in Trusted Extensions
Enable Users to Access Their Home Directories in Trusted Extensions
Adding Users and Hosts to an Existing Trusted Network
Add an NIS User to the LDAP Server
Troubleshooting Your Trusted Extensions Configuration
netservices limited Was Run After Trusted Extensions Was Installed
Cannot Open the Console Window in a Labeled Zone
Labeled Zone Is Unable to Access the X Server
Additional Trusted Extensions Configuration Tasks
How to Copy Files to Portable Media in Trusted Extensions
How to Copy Files From Portable Media in Trusted Extensions
How to Remove Trusted Extensions From the System
5. Configuring LDAP for Trusted Extensions (Tasks)
6. Configuring a Headless System With Trusted Extensions (Tasks)
B. Using CDE Actions to Install Zones in Trusted Extensions
If you are already using administrative roles, you might want to add a Security Administrator role. For sites that have not yet implemented roles, the procedure for creating them is similar to the procedure in the Solaris OS. Trusted Extensions adds the Security Administrator role and requires the use of the Solaris Management Console to administer a Trusted Extensions domain.
Role creation in Trusted Extensions is identical to role creation in the Solaris OS. However, in Trusted Extensions, a Security Administrator role is required. To create a local Security Administrator role, you can also use the command-line interface, as in Example 4-4.
You must be superuser, in the root role, or in the Primary Administrator role.
To create the role on the network, you must have completed Configuring the Solaris Management Console for LDAP (Task Map).
# /usr/sbin/smc &
You are prompted for your password.
Use the following information as a guide:
Role name – secadmin
Full name – Security Administrator
Description – Site Security Officer No proprietary information here.
Role ID Number – ≥100
Role shell – Administrator's Bourne (profile shell)
Create a role mailing list – Leave the checkbox selected.
Password and confirm – Assign a password of at least 6 alphanumeric characters.
The password for the Security Administrator role, and all passwords, must be difficult to guess, thus reducing the chance of an adversary gaining unauthorized access by attempting to guess passwords.
Note - For all administrative roles, make the account Always Available, and do not set password expiration dates.
Available and Granted Rights – Information Security, User Security
Home Directory Server – home-directory-server
Home Directory Path – /mount-path
Assign Users– This field is automatically filled in when you assign a role to a user.
Select the role, then double-click it.
Review the values in the following fields:
Available Groups – Add groups if required.
Trusted Extensions Attributes – Defaults are correct.
For a single-label system where the labels must not be visible, choose Hide for Label: Show or Hide.
Audit Excluded and Included – Set audit flags only if the role's audit flags are exceptions to the system settings in the audit_control file.
For examples, see How to Create and Assign a Role by Using the GUI in System Administration Guide: Security Services. Give each role a unique ID, and assign to the role the correct rights profile. Possible roles include the following:
admin Role – System Administrator Granted Rights
primaryadmin Role – Primary Administrator Granted Rights
oper Role – Operator Granted Rights
Example 4-4 Using the roleadd Command to Create a Local Security Administrator Role
In this example, the root user adds the Security Administrator role to the local system by using the roleadd command. For details, see the roleadd(1M) man page. The root user consults Table 1-2 before creating the role.
# roleadd -c "Local Security Administrator" -d /export/home1 \ -u 110 -P "Information Security,User Security" -K lock_after_retries=no \ -K idletime=5 -K idlecmd=lock -K labelview=showsl \ -K min_label=ADMIN_LOW -K clearance=ADMIN_HIGH secadmin
The root user provides an initial password for the role.
# passwd -r files secadmin New Password: <Type password> Re-enter new Password: <Retype password> passwd: password successfully changed for secadmin #
To assign the role to a local user, see Example 4-5.
To create a local user, you can use the command-line interface, as in Example 4-5, instead of the following procedure. Where site security policy permits, you can choose to create a user who can assume more than one administrative role.
For secure user creation, the System Administrator role creates the user, and the Security Administrator role assigns security-relevant attributes, such as a password.
You must be superuser, in the root role, in the Security Administrator role, or in the Primary Administrator role. The Security Administrator role has the least amount of privilege that is required for user creation.
The Solaris Management Console is displayed. For details, see Create the Security Administrator Role in Trusted Extensions.
Caution - The names and IDs of roles and users come from the same pool. Do not use existing names or IDs for the users that you add. |
You can also follow the procedures in How to Add a User With the Solaris Management Console’s Users Tool in System Administration Guide: Basic Administration.
Note - For users who can assume roles, make the user account Always Available, and do not set password expiration dates.
Ensure that the following fields are correctly set:
Description – No proprietary information here.
Password and confirm – Assign a password of at least 6 alphanumeric characters.
Note - When the install team chooses a password, the team must select a password that is difficult to guess, thus reducing the chance of an adversary gaining unauthorized access by attempting to guess passwords.
Account Availability – Always Available.
Trusted Extensions Attributes – Defaults are correct.
For a single-label system where the labels must not be visible, choose Hide for Label: Show or Hide.
Account Usage – Set Idle time and Idle action.
Lock account – Set to No for any user who can assume a role.
After checking your site security policy, you might want to grant your first users the Convenient Authorizations rights profile. With this right, users can allocate devices, print PostScript files, print without labels, remotely log in, and shut down the system.
On a multilabel system, users and roles can be set up with files that list user initialization files to be copied or linked to other labels. For more information, see .copy_files and .link_files Files in Solaris Trusted Extensions Administrator’s Procedures.
Example 4-5 Using the useradd Command to Create a Local User
In this example, the root user creates a local user who can assume the Security Administrator role. For details, see the useradd(1M) and atohexlabel(1M) man pages.
First, the root user determines the hexadecimal format of the user's minimum label and clearance label.
# atohexlabel public 0x0002-08-08 # atohexlabel -c "confidential restricted" 0x0004-08-78
Next, the root user consults Table 1-2, and then creates the user.
# useradd -c "Local user for Security Admin" -d /export/home1 \ -K idletime=10 -K idlecmd=logout -K lock_after_retries=no -K min_label=0x0002-08-08 -K clearance=0x0004-08-78 -K labelview=showsl jandoe
Then, the root user provides an initial password.
# passwd -r files jandoe New Password: <Type password> Re-enter new Password: <Retype password> passwd: password successfully changed for jandoe #
Finally, the root user adds the Security Administrator role to the user's definition. The role was created in Create the Security Administrator Role in Trusted Extensions.
# usermod -R secadmin jandoe
To verify each role, assume the role. Then, perform tasks that only that role can perform.
If you have configured DNS or routing, you must reboot after you create the roles and before you verify that the roles work.
$ /usr/sbin/smc &
You are prompted for a password.
The System Administrator role should be able to modify fields under the General, Home Directory, and Group tabs.
The Security Administrator role should be able to modify fields under all tabs.
The Primary Administrator role should be able to modify fields under all tabs.
When the host is rebooted, the association between the devices and the underlying storage must be re-established.
You have created at least one labeled zone. That zone is not being used for cloning.
# svcs zones STATE STIME FMRI offline - svc:/system/zones:default
# svcadm restart svc:/system/zones:default
Regular users can now log in. Their session is in a labeled zone.