Creating Roles and Users in Trusted Extensions

Role creation in Trusted Extensions is identical to role creation in Oracle Solaris. However, for an evaluated configuration, a Security Administrator role is required.

How to Create the Security Administrator Role in Trusted Extensions

Before You Begin

You are in the root role in the global zone.

1. To create the role, use the roleadd command.

   For information about the command, see the roleadd(1M) man page.

   Use the following information as a guide:

   • Role name – secadmin

   • -c Local Security Officer

     Do not provide proprietary information.

   • -m home-directory

   • -u role-UID

   • -S repository

   • -K key=value

     Assign the Information Security and User Security rights profiles.

     ---

     Note - For all administrative roles, use the administrative labels for the label range, audit uses of the pfexec command, set lock_after_retries=no, and do not set password expiration dates.

     ---

   # roleadd -c "Local Security Officer" -m \
   -u 110 -K profiles="Information Security,User Security" -S files \
   -K lock_after_retries=no \
   -K min_label=ADMIN_LOW -K clearance=ADMIN_HIGH secadmin

2. Provide 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
   #

   Assign a password of at least six 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.

3. Use the Security Administrator role as a guide when you create other roles.

   Possible roles include the following:

   • admin Role – System Administrator rights profile

   • oper Role – Operator rights profile

Example 4-4 Creating the Security Administrator Role in LDAP

After configuring the first system with a local Security Administrator role, the administrator creates the Security Administrator role in the LDAP repository. In this scenario, LDAP clients can be administered by the Security Administrator role that is defined in LDAP.

# roleadd -c "Site Security Officer" -d server1:/rpool/pool1/BayArea/secadmin
-u 111 -K profiles="Information Security,User Security" -S ldap \
-K lock_after_retries=no -K audit_flags=lo,ex:no \
-K min_label=ADMIN_LOW -K clearance=ADMIN_HIGH secadmin

The administrator provides an initial password for the role.

# passwd -r ldap secadmin
New Password:        <Type password>
Re-enter new Password: <Retype password>
passwd: password successfully changed for secadmin
#

Next Steps

To assign the local role to a local user, see How to Create Users Who Can Assume Roles in Trusted Extensions.

How to Create a System Administrator Role

Before You Begin

You are in the root role in the global zone.

1. Assign the System Administrator rights profile to the role.

   # roleadd -c "Local System Administrator" -m -u 111  -K audit_flags=lo,ex:no\
   -K profiles="System Administrator" -K lock_after_retries=no \
   -K min_label=ADMIN_LOW -K clearance=ADMIN_HIGH sysadmin

2. Provide an initial password for the role.

   # passwd -r files sysadmin
   New Password:        <Type password>
   Re-enter new Password: <Retype password>
   passwd: password successfully changed for sysadmin
   #

How to Create Users Who Can Assume Roles in Trusted Extensions

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 assigns the initial password, and the Security Administrator role assigns security-relevant attributes, such as a role.

Before You Begin

You must be in the root role in the global zone. Or, if separation of duty is enforced, users who can assume the distinct roles of Security Administrator and System Administrator must be present to assume their roles and perform the appropriate steps in this procedure.

1. Create a user.

   Either the root role or the System Administrator role performs this step.

   Do not place proprietary information in the comment.

   # useradd -c "Second User" -u 1201 -d /home/jdoe jdoe

2. After creating the user, modify the user's security attributes.

   Either the root role or the Security Administrator role performs this step.

   ---

   Note - For users who can assume roles, turn off account locking, and do not set password expiration dates. Also, audit uses of the pfexec command.

   ---

   # usermod -K lock_after_retries=no -K idletime=5 -K idlecmd=lock \
   -K audit_flags=lo,ex:no jdoe

   ---

   Note - The values for idletime and idlecmd continue in effect when the user assumes a role. For more information, see policy.conf File Defaults in Trusted Extensions.

   ---

3. Assign a password of at least six alphanumeric characters.

   # passwd jdoe
   New Password: Type password
   Re-enter new Password:Retype password

   ---

   Note - When the initial setup 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.

   ---

4. Assign a role to the user.

   The root role or the Security Administrator role performs this step.

   # usermod -R oper jdoe

5. Customize the user's environment.
   1. Assign convenient authorizations.

      After checking your site security policy, you might want to grant your first users the Convenient Authorizations rights profile. With this profile, users can allocate devices, print without labels, remotely log in, and shut down the system. To create the profile, see How to Create a Rights Profile for Convenient Authorizations.

   2. Customize user initialization files.

      See Customizing the User Environment for Security (Task Map).

   3. Create multilevel copy and link files.

      On a multilevel 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.

Example 4-5 Using the useradd Command to Create a Local User

In this example, the root role creates a local user who can assume the Security Administrator role. For details, see the useradd(1M) and atohexlabel(1M) man pages.

This user is going to have a label range that is wider than the default label range. So, the root role 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 role consults Table 1-2, and then creates the user. The administrator places the user's home directory in /export/home1 rather than the default, /export/home.

# useradd -c "Local user for Security Admin" -d /export/home1/jandoe \
-K  idletime=10 -K idlecmd=logout -K lock_after_retries=no
-K min_label=0x0002-08-08 -K clearance=0x0004-08-78 jandoe

Then, the root role assigns 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 role adds the Security Administrator role to the user's definition. The role was created in How to Create the Security Administrator Role in Trusted Extensions.

# usermod -R secadmin jandoe

How to Verify That the Trusted Extensions Roles Work

To verify each role, assume the role. Then, perform tasks that only that role can perform and attempt tasks that the role is not permitted to perform.

Before You Begin

If you have configured DNS or routing, you must reboot after you create the roles and before you verify that the roles work.

1. For each role, log in as a user who can assume the role.
2. Assume the role.

   In the following trusted stripe, the user name is tester.

   
   
   1. Click your user name in the trusted stripe.
   2. From the list of roles that are assigned to you, select a role.
3. Test the role.

   For the authorizations that are required to change user properties, see the passwd(1) man page.

   • The System Administrator role should be able to create a user and modify user properties that require the solaris.user.manage authorization, such as the user's login shell. The System Administrator role should not be able to change user properties that require the solaris.account.setpolicy authorization.

   • The Security Administrator role should be able to change user properties that require the solaris.account.setpolicy authorization. The Security Administrator should not be able to create a user or change a user's login shell.

How to Enable Users to Log In to a Labeled Zone

When the system is rebooted, the association between the devices and the underlying storage must be re-established.

Before You Begin

You have created at least one labeled zone. After configuring the system, you rebooted. You can assume the root role.

1. Log in and assume the root role.
2. Check the state of the zones service.

   # svcs zones
   STATE          STIME    FMRI
   offline        -        svc:/system/zones:default

3. Restart the service.

   # svcadm restart svc:/system/zones:default

4. Log out.

   Regular users can now log in. Their session is in a labeled zone.