Chapter 2 Administering Security Requirements

This chapter provides information about notifying users about security, changing security defaults, extending existing security mechanisms, and getting security information. Most of these tasks involve modifying files on a local system. This chapter contains the following procedures:

• "To Change the Allowed Number of Password Tries"

• "To Prevent Account Locking for Individuals"

• "To Prevent Account Locking for All User Accounts"

• "SPARC: To Enable Keyboard Shutdown"

• "To Prevent Logins From Being Disabled After a Reboot"

• "To Modify the Selection Configuration File"

• "To Change Configurable Kernel Switch Settings"

• "To Add an Authorization to the Environment"

• "To Add a Privilege to the Environment"

• "To Get a Hexadecimal Equivalent for a Label"

• "To List a User's Home Directory SLDs and Their Labels"

Enforcing Security Requirements

To ensure that the security of the system is not compromised, administrators need to protect passwords, files and audit data and to train computer users to do their part. To be consistent with the requirements for an evaluated configuration, follow the guidelines in this section.

Training Users About Security Requirements

Each site's security administrator ensures users are trained. The security administrator should hand off the following rules to new employees and remind existing employees of these rules from time to time.

Your organization may wish to provide additional suggestions beyond those listed below.

Users' Security Rules

Anyone who knows your password can access the same information that you can without being identified and therefore without being accountable.

Do not tell anyone else the password.

Do not write the password down or include it in an email message.

Choose passwords that are hard to guess.

Do not leave your computer unattended without locking the screen or logging off.

Be aware that sender information in email can be forged.

Remember that administrators do not rely on email to send instructions to users. Do not ever follow instructions from administrators in an email without first double-checking with the administrator.

Do not send your password to anyone by email.

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 do not allow unauthorized users to read or change a file or list the contents of or write into a directory.

Using Email

It is poor 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. This 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.

Enforcing Password Requirements

The System Administrator role is responsible for specifying the original password for each account and for handing off the passwords to new accounts. The System Administrator role must specify a unique user name and a unique user ID when creating a new account. When choosing the name and ID for a new account, the administrator must ensure that both the user name and associated UID are not duplicated anywhere on the network and have not been previously used.

Security Administrator Password Administration Rules

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 ensures that at least one account can always log in and assume the Security Administrator role to reopen everyone's account if it ever happens that all other accounts are locked.

Hand over the password to an account in such a way that the password cannot be eavesdropped by anyone else.

Change an account's password if there is any suspicion that the password has been discovered by anyone who should not know it.

Never reuse user names or UIDs over the lifetime of the system.

Ensuring that user names and UIDs are not reused prevents possible confusion over:

• Which actions were performed by which user when audit records are analyzed

• Which user owns which files when archived files are restored

Changing Root's Password

The Security Administrator role can change any account's password at any time except for the password of the root role. Because root's UID 0 is below 100, the SMC considers root to be a "system account," and the SMC does not allow any changes to be made to system accounts. If root's password needs to be changed, root must make the change using the TP menu Change Password option.

Protecting Information

Administrators are responsible for correctly setting up and maintaining DAC and MAC protections for security-critical files, such as the shadow(4) file containing encrypted passwords, the local prof_attr(4), exec_attr(4), and user_attr(4) databases, and the audit trail.

Because the protection mechanisms for NIS maps and NIS+ tables are not subject to the access control policy enforced by the Trusted Solaris software, the default NIS maps and NIS+ tables should not be extended, and their access rules should not be modified.

Protecting Passwords

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 shadow(4) file that is readable only by root: The Security Administrator role should ensure that the /etc/shadow file is protected by MAC at ADMIN_LOW, and by DAC by root (owner), sys (group), and 400.

trusted4% ls -l /etc/shadow; getlabel /etc/shadow
-r--------   1 root     sys          307 Sep 7  2001 /etc/shadow
/etc/shadow:    [ADMIN_LOW]

The password field in the NIS+ passwd.org_dir table is protected by NIS+ restrictions on access to fields within tables. When any user or administrator tries to view the passwd.org_dir table, the only encrypted password that displays is the one belonging to the account.

The following example shows that while user ashish's password field shows as *NP* when the user roseanne invoked the niscat(1) command, barbar can see the encrypted password for her own account.

trusted5% whoami
roseanne
trusted6% niscat passwd.org_dir
. . .
ashish:*NP*:33333:10:Ash Ish:/home/ashish:/bin/csh:*NP*
barbar:0dk1EW44:10:Bar Bara:/home/barbara:/bin/csh:38442::::::

There is no shadow.org_dir table.

With NIS, configure the shadow database as a secure map. Secure maps are only readable from a privileged port, thus only a privileged program could access the encrypted password. Sites that need more security than NIS provides should use NIS+.

Administering Groups

The admin 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 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.

Deleting Users

When an account is deleted from the system, the administrator and Security Administrator must take the following actions:

• The account's home directory must be deleted.

• Any processes or jobs belonging to the deleted account must be removed:

  • Any objects owned by the account must be deleted or the ownership must be assigned to another user.

  • Any at or batch jobs scheduled on behalf of the user must be deleted. See the at(1) and crontab(1) man pages, if needed.

• The user (account) name and UID must be retired and not reused.

Changing Number of Allowable Password Tries

By default, the Trusted Solaris environment allows a maximum of five failed attempts to enter the correct password during a single access attempt. If a user or role account enters the wrong password one time too many during a single attempt, the account is locked. Having such a limit helps forestall brute force attempts to gain access by guessing multiple different passwords.

A count of incorrect passwords entered during a single attempt is kept in the flag field of the user or role's entry in the local shadow(4) file or in the NIS+ table.

Because NIS does not make the flag field of the shadow database available, a count of failed retries cannot be maintained on a system that relies on the NIS name service. If enforcing a maximum number of failed login attempts is essential to your site's security policy, use either NIS+ or local files.

If the user or role enters the correct password before the count exceeds the maximum, the flag is re-set to zero (0). If an account enters the wrong password one time too many during a single session, the account is locked, as described in the passwd(4) man page.

The number of retries allowed applies only for multiple bad passwords entered in sequence in either of the following two occasions:

• When logging into a host

• When re-authenticating oneself in order to change a password or to assume a role.

If an account is ever locked by inadvertent error, the Security Administrator role can open the account by giving the user a new password using the Password tab in the User Accounts tool or by using the appropriate options with the smuser(1M) command line interface.

The Security Administrator role can change the RETRIES limit system-wide and can also change whether the limit applies to all users or individual users. Following are the actions that can be taken to change the default:

• The Security Administrator role can change the maximum number of retries to be any number that is consistent with the site's security policy.

  The procedure, "To Change the Allowed Number of Password Tries", describes how to set the RETRIES value in the local /etc/default/login file.

• The Security Administrator role can specify that any individual user's account cannot be locked or can change the default system wide, so that account locking does not occur for anyone. Role accounts, since they do not log in directly, cannot be locked. The entries for individual users take precedence over system-wide entries, which in turn take precedence over the system default.

  The procedure, "To Prevent Account Locking for Individuals", describes how to update a user's account with the User Accounts tool to prevent the account from being locked. The procedure, "To Prevent Account Locking for All User Accounts", describes how to set a system-wide password lock policy.

Managing the Relabeling of Files

By default, normal users can perform cut and paste, copy and paste, and drag and drop operations on both files and selections as long as the source and destination have the same label and have the same user ID.

The /usr/dt/config/sel_config file is consulted to determine which actions will be taken when an operation would upgrade or downgrade a label. (The comments and keywords in the file use the terms sensitivity label and label interchangeably.)

The rules that apply when some operations are performed on file icons differ from the rules that apply when the same operations are performed on selections made in windows. Drag and drop of selections always requires equality of labels and ownership.

The sel_config file defines:

• A list of selection types to which automatic replies are given

• Whether certain types of operation should be automatically confirmed or

• Whether a selection confirmer dialog should be displayed

  The following figure shows the selection confirmer for drag and drop operations between File Managers. Other slightly-different selection confirmers display for cut and paste and copy and paste operations between File Managers and between windows at varying labels.

  Figure 2-1 File Manager Selection Confirmer

  
  

The Security Administrator role can change the defaults by using the Selection Configuration action. The new settings become effective the next time anyone logs in.

Users can copy and paste between file managers that they own and that are at the same label. The types of operations that may be performed on files with varying label and ownership relationships are summarized and shown with the authorizations needed, in the following table.

Users can copy and paste between windows that they own and that are at the same label.The types of operations that may be performed on selections between windows with varying label and ownership relationships are summarized and shown with the authorizations needed in the following table.

sel_config File Sections

The rules in the sel_config file apply to cut and paste, copy and paste, and drag and drop of files between file managers. (See dtfile(1) and the Trusted Solaris User's Guide for more about the File Manager application.) The rules in the sel_config file also apply to cut and paste and copy and paste between windows. Drag and drop between windows is mediated by the /usr/dt/bin/sel_mgr application, not by sel_config.

The sel_config file has two sections described below:

• Automatic confirmation

• Automatic reply

Automatic Confirmation Section

The format of each line in the automatic confirmation section of the sel_config file is shown in the following table. label-relation refers to the relationship between the label of the source and the label of the destination, and the value n means to display the selection confirmer to the user.

Automatic Reply Section

The autoreply field defines the type of reply for all the named types of selections that follow it. This section provides a way to reply automatically to several types of selections at once instead of having to respond to each individually. See the sel_config(4) man page for more information.

Extending Authorizations and Privileges

The following Trusted Solaris security mechanisms are extendable:

• Audit events and classes--Adding audit events and audit classes is described in the Trusted Solaris Audit Administration.

• Rights profiles--Adding rights profiles is described in "Adding or Modifying a Rights Profile".

• Roles--Adding roles is described in "Creating a New Role".

• Authorizations and privileges--The rest of this section describes how to add authorizations and privileges.

Adding New Authorizations

Adding a new authorization consists of:

1. Adding a header entry for the site's authorizations into the auth_attr(4) database.

2. Adding a grant authorization into the auth_attr database that enables a role to assign the new authorization to others.

3. Adding the new authorization entry to the auth_attr database.

4. If you are running a name service, adding the new entries to the name service auth_attr database.

5. Writing or modifying an application to check for the new authorization.

   In a default Trusted Solaris system, only the device allocation mechanism accepts new authorizations. Of course, a site can write other applications that check for new authorizations.

   The example detailed in "To Add an Authorization to the Environment" makes use of the fact that the device allocation authorization is configurable.

6. Assigning the new authorization to user or role accounts.

The format for an entry in the auth_attr(4) file is:

name:res1:res2:short_desc:long_desc:attr

The short_desc field is a brief description of the activity permitted by the authorization. The long_desc is used by the Solaris Management Console when it displays authorizations. A help file, which is specified in the attr field using the keyword value pair help=filename, displays in the online help. filename must be located in the directory ending with the name of the locale: /usr/lib/help/auths/locale/localename.

The following screen shows the default device allocation authorization in the auth_attr file in the C locale. The help file in the C locale is /usr/lib/help/auths/locale/C/DevAllocate.html.

solaris.device.allocate:::Allocate Device::help=DevAllocate.html
 

The example below shows two finer-grained device allocation authorizations that could be used to replace the default one above, one for tape devices and one for floppy devices. In the example, the authorizations' names start with the Internet domain name of the NewCo company.

com.newco.device.allocate.tape:::Allocate Tape Device::help=TapeAllocate.html
com.newco.device.allocate.floppy:::Allocate Floppy Device::help=FloppyAllocate.html

The next example shows the solaris.allocate.device authorization replaced in the device_allocate(4) file entry for floppy_0 with com.newco.device.allocate.floppy. This change would be made by the Security Administrator role using the Device Allocation Manager, as described in "To Add an Authorization to the Environment". After this substitution, any user attempting to allocate the floppy device must have the new authorization.

floppy_0;fd;0x00000000000000000000000000000000000000000000000000000000000000000
000;0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff;com.
newco.device.allocate.floppy;/etc/security/lib/disk_clean

Adding New Privileges

Adding a new privilege consists of adding an entry for the privilege into these two files:

• /usr/include/sys/tsol/priv_names.h

• /usr/lib/tsol/locale/C/priv_name

The priv_names.h File

The /usr/include/sys/tsol/priv_names.h header file contains manifest constants and associated numbers for privileges. Up to 128 possible privileges are allowed. As shown in the following screen example, the definitions for the default privileges range from 1 to 86 (with 0 meaning no privileges). Not all 86 privileges are defined since some have been retired.

The manifest constants and numbers for default privileges in priv_names.h are:

PRIV_FILE_AUDIT = 1,		/* operational */
PRIV_FILE_CHOWN = 2,		/* operational */
PRIV_FILE_DAC_EXECUTE = 3,	/* policy */
										.						
										.						
										.						
PRIV_WIN_SELECTION = 84,	/* operational */
PRIV_WIN_UPGRADE_SL = 86,	/* operational */
 

Privileges available for extension follow the /* Reserved for ISV..*/ text in the file:

/* Reserved for ISV, GOTS, integrator, ... use */
										.						
										.						
	reserved127 = 127,
	reserved128 = 128

If you wish to interoperate with other systems, you should contact your Trusted Solaris representative to reserve a privilege number.

The priv_name File

The following is the format for an entry in /usr/lib/tsol/locale/locale_name/priv_name:

number:name:description

The value of number in the priv_name(4) file must match the privilege ID in the /usr/include/sys/tsol/priv_names.h file. name must be concise and descriptive for display in user interfaces.

description describes the activity permitted by the privilege. The definition guides the Security Administrator role when assigning privileges to programs.

The following is an example of a privilege in the default priv_name file:

4:file_dac_read:Allows a process to read a file or directory \
whose permission bits or ACL do not allow the process read permission.

Changing CDE Defaults

In the default CDE environment, users can add actions to the Front Panel and customize the Workspace menu. Trusted Solaris software limits users' ability to add programs and commands to the CDE.

Customizing the Workspace Menu

The Workspace Menu is the menu accessed by clicking and holding the right mouse (Menu) button on the background of the workspace. Using the Customize Menu and Add Item to Menu options on the Workspace Menu is the same as in the base CDE window system, with some Trusted Solaris protections.

The following apply when a user is allowed to work at multiple labels:

• The user must use the Customize Menu and Add Item to Menu options in a workspace labeled at the session clearance. Changes made at other labels than the session clearance are not recognized by the window system.

  If a user is able to log in at multiple labels, the user has the potential for multiple session clearances during different login sessions. Therefore, make any changes at each of the potential session clearances if you want the changes to apply to all potential login sessions.

• The user makes the changes in a normal user workspace.

• When the user assumes a role, changes to the Workspace Menu persist.

• Changes made to the Workspace Menu are stored in the user's home directory in the single-level directory (SLD) created at the working label. The label should be the same as the session clearance. The items in the Workspace Menu are stored in the .dt/wsmenu directory within the user's multilevel (MLD) home directory in the SLD that corresponds to the working label.

  For example, to change the Workspace Menu when the user's only possible session clearance is NEED_TO_KNOW ENG, the user would go to a workspace labeled NEED_TO_KNOW ENG. If the user adds an item to the Applications menu using the Add Item to Menu option, the item would be stored in /home/username/.dt/wsmenu/Applications.

  The pathname above corresponds to the real MLD path shown below, where .SLD.3 in the example is the SLD that corresponds to the NEED_TO_KNOW ENG label for user barbar.

  /home/.MLD.barbar/.SLD.3/.dt/wsmenu/Applications

• The profile mechanism must enble the user to run the action.

  Any option added to the Workspace Menu must be handled by one of the user's rights profiles or the option will fail when invoked and an error message will display.

  For example, anyone with the Run action can double-click the icon for any executable and run it, even if the action or any commands it invokes are not in one of the account's rights profiles. By default, roles do not have the Run action, and all executable actions require the Run action, and therefore, any item that requires the Run action fails when executed by a role.

Customizing the Front Panel

Anyone can drag and drop a pre-existing action from the Application Manager to the Front Panel as long as the account doing the modification has the action in its profile. Actions in the /usr/dt/* or /etc/dt/* directories can be added to the Front Panel, but applications in the $HOME/.dt/appconfig directories cannot. While users can use the Create Action action, they cannot write into any of the directories where the system-wide actions are stored, so they cannot use the actions.

In the Trusted Solaris environment, the actions' search path has been changed so that actions in any individual's home directory are processed last instead of first. Therefore, no one can customize existing actions.

The Security Administrator role has the Admin Editor action, so can make any needed modifications to the /usr/dt/appconfig/types/C/dtwm.fp file and the other configuration files for the Front Panel subpanels. This guide contains two procedures that exemplify how to modify existing files to create new actions. "To Add Actions Outside of the System_Admin Folder" describes how to create an alternate mail application that can run with privilege in the Front Panel. "dtmail is the Default Mail Application" describes how to add an administrative action that can run with inherited privileges to the System_Admin folder for the purpose of editing another configuration file.

Roles can drag and drop actions from the System_Admin folder to the Front Panel. The icons can confuse normal users because the action icons only work for the roles.

Changing and Accessing Security Information (Tasks)

To Change the Allowed Number of Password Tries

1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

2. Use the Admin Editor action to open the /etc/default/login file for editing.

   See "To Edit a Local File", if needed.

3. Search for the string #RETRIES.

   # RETRIES sets the number of consecutive authentication failures # allowed before the user is locked out. # #RETRIES=5

4. Change the RETRIES value to the desired value and remove the # sign.

5. Save and close the file.

To Prevent Account Locking for Individuals

1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

2. Bring up the Solaris Management Console on the desired server with the desired scope, either Files, NIS, or NIS+.

   See "To Launch the Solaris Management Console", if needed, for how to bring up the Solaris Management Console.

3. Bring up the User Accounts tool by clicking the Trusted Solaris Configuration icon, then clicking the Users icon. Enter the role password when prompted.

4. If the user account does not exist, create it by double-clicking the User Accounts icon in the Navigation pane, clicking Add User in the Action menu, and then choosing With Wizard or From Template.

   Follow the instructions in the help text for how to fill in the fields to add a user account.

5. Open the User Properties tool by double-clicking the User Accounts icon, then double-clicking the name of the user.

   The Properties dialog displays.

6. Click the Trusted Solaris Attributes tab.

7. In the Account Usage section, select No from the pull-down menu next to Lock account after maximum failed logins.

To Prevent Account Locking for All User Accounts

1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

   See "To Log In and Assume a Role", if needed.

2. At ADMIN_LOW, use the Admin Editor action to open the /etc/security/policy.conf file for editing.

   See "To Edit a Local File", if needed.

3. Search for the string LOCK_AFTER_RETRIES.

   LOCK_AFTER_RETRIES=yes

4. Change yes to no, or if the string is not present in the file, add the following.

   LOCK_AFTER_RETRIES=no

5. Save and quit the file.

   :wq

SPARC: To Enable Keyboard Shutdown

By default, Trusted Solaris systems can only be brought down by an orderly shutdown through the Shut Down option from the Trusted Path menu. The Stop-A keyboard shutdown does not work.

Where the site's security policy allows, the default setting can be changed. On hosts that are used by administrators for debugging, this setting can be changed to allow access to the kadb(1M) kernel debugger.

1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

2. Use the Admin Editor action to open the /etc/default/kbd file for editing.

   See "To Edit a Local File", if needed.

3. Search for the string KEYBOARD_ABORT.

   KEYBOARD_ABORT=disable

4. Enter a pound sign at the start of the line to comment it out.

   #KEYBOARD_ABORT=disable

To Prevent Logins From Being Disabled After a Reboot

In the Trusted Solaris environment, the /etc/nologin file is created after boot and is not removed until a user with the Enable Logins authorization enables logins.

If your site's security policy allows, the Security Administrator role can edit the RMTMPFILES script in /etc/init.d to comment out the lines that recreate the /etc/nologin file. See "To Prevent Logins From Being Disabled After a Reboot", if changing the default is consistent with your site's security policy.

1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

2. Use the Admin Editor action to open the /etc/init.d/RMTMPFILES for editing.

   See "To Edit a Local File", if needed.

   ---

   Note -

   Do not create a backup file in the /etc/init.d directory. Because all files in the startup directories are executed, the backup file would be executed after the changed version, so the /etc/nologin file would be re-created, and the effect of this procedure would be undone.

   ---

3. Comment out the lines that disable logins after a reboot.

   Comment out the active lines as shown in the following screen.

   # cp /dev/null /etc/nologin # echo "" >> /etc/nologin # echo "NO LOGINS: System booted" >> /etc/nologin # echo "Logins must be enable by an authorized user." >> # /etc/nologin # echo "" >> /etc/nologin

4. Save and quit the file.

   :wq

To Change Configurable Kernel Switch Settings

1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

2. Use the Admin Editor action from the System_Admin folder in the Application Manager to open /etc/system for editing.

3. Set the configurable switches as desired, then save the file.

   See Table 2-3 for a description of the switches.

4. Reboot the system for the values to go into effect.

The following table shows the customer-configurable kernel switches in the system(4) file.

To Modify the Selection Configuration File

1. Assume the System Administrator role and go to an ADMIN_LOW workspace.

2. Go to the System_Admin folder in the Application Manager.

3. Double-click the Selection Configuration action to open the sel_config file for editing.

   See "Managing the Relabeling of Files" for what the fields mean, if needed.

4. Save the changes.

   The settings go into effect at the next login.

To Add an Authorization to the Environment

1. Log in and assume the Security Administrator role and go to an ADMIN_LOW workspace.

2. Use the Admin Editor action in the System_Admin folder in the Application Manager to open the auth_attr file for editing.

   ---

   Note -

   If you are using a name service, you need to make the changes in this procedure to the auth_attr(4) file in the location from which you populate the entries to the NIS map or NIS+ table. See the Solaris Naming Administration Guide for how to populate the name service databases with the new entries.

   ---

3. Create a heading for the new authorizations, using the reverse-order Internet domain name of your organization followed by optional additional arbitrary components. Separate components by dots. End heading names with a dot.

   The example shows a heading constructed for a company whose Internet domain name is newco.com. The name of the company is followed by a dot (.).

   com.newco.:::NewCo Header::help=NewCo.html

4. Add new authorization entries.

   The example shows the authorization to grant all NewCo authorizations, followed by the authorization to grant NewCo's device authorizations, followed by a new tape device allocation authorization, followed by a new floppy device allocation authorization.

   com.newco.grant:::Grant All NewCo Authorizations:: help=GrantNewco.html com.newco.grant.device:::Grant NewCo Device Authorizations:: help=GrantNewcoDevice.html com.newco.device.allocate.tape:::Allocate Tape Device:: help=TapeAllocate.html com.newco.device.allocate.floppy:::Allocate Floppy Device:: help=FloppyAllocate.html

   Enter the authorizations one per line. The lines above are split here to fit on the page.

5. Save and close the file.

   :wq

6. If you are using a naming service, update the auth_attr NIS map or NIS+ table.

   See the nistbladm(1) man page and the Solaris Naming Administration Guide for how to update the auth_attr(4) map or table.

7. Add the authorization to the database that defines which authorizations the application requires.

   For example, to assign the new device allocation authorization, you would use the Device Allocation Manager. See "To Add Site-Specific Authorizations to a Device" for the procedure.

8. Use the Rights tool to add the new authorizations to the Custom rolename Role, and make sure the Custom rolename Role rights profile is assigned to the role.

To Add a Privilege to the Environment

Before you add a privilege, contact your Trusted Solaris representative to reserve a privilege number.

1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

2. Use the Admin Editor action to open the /usr/include/sys/tsol/priv_names.h file for editing.

   See "To Edit a Local File", if needed.

3. Follow the directions in the comment at the top of the priv_names.h file, shown below.

   / * * ********************** IMPORTANT ********************** * * The privilege names should be maintained in alphabetical order * not numeric order. * * When a privilege is retired it should be placed in the appropriate * reserved area in the form "tsol_reserved## = ##," or * "reserved## = ##". * * When a new privilege is needed, it should be taken from the first * available privilege in the appropriate reserved area. * * ISVs, GOTS', integrators who need privileges are encouraged to * request and retire them by contacting their respective Trusted * Solaris support representative. * * This file is parsed by the priv_to_str(3) functions. * * In order to guarantee correct parsing, the format of the * following priv_t definition must be preserved. * * Specifically, the following guidelines must be followed: * * 1. All privileges must have an explicitly assigned id. * DO NOT RELY ON COMPILER TO ASSIGN IDs. * * 2. One privilege id assignment per line. * DO NOT CONCATENATE OR BREAK LINES. * * 3. Do not use the `=' character at anywhere other than * the privilege id assignment. * For example, DO NOT use `=' in the comments.

4. Create an entry in the priv_names.h file with the manifest constant for the privilege.

   A sample entry is below.

   PRIV_RISKY = 90,

5. Save and close the file.

6. Use the Admin Editor action to open the /usr/lib/tsol/locale/locale_name/priv_name file for editing.

   In the C locale, for example, you would edit the /usr/lib/tsol/locale/C/priv_name file.

7. Create an entry with the privilege ID, name, and definition for the privilege in the priv_name file.

   ---

   Note -

   Make sure that you use the correct privilege ID.

   ---

   A sample entry is below.

   90:override everything:Allows a process to bypass all MAC and \ DAC checks and auditing flag settings and be otherwise totally \ unaccountable.

8. Save and close the file.

9. Copy the changed priv_names.h and priv_name files or make the same change in these files on all computers in the Trusted Solaris network.

To Customize the Workspace Menu

To make the changes apply to every possible login session, users with multiple labels need to repeat these steps at every label that corresponds to a potential session clearance.

1. Log in and go to a workspace whose label is the same as the session clearance--without assuming a role.

2. Choose the Customize Menu or Add Item to Menu option from the Workspace Menu and make the desired changes.

To Get a Hexadecimal Equivalent for a Label

Use atohexlabel(1M) with the options shown in the following steps to get the hexadecimal equivalents of a label or clearance. The atohexlabel(1M) command is in the default Object Label Management profile, which is assigned by default to the Security Administrator role.

1. Assume the Security Administrator role and create an ADMIN_HIGH workspace.

   To get the hexadecimal value for a sensitivity label, use atohexlabel with the -s option followed by the name of the sensitivity label.

   $ atohexlabel -s SECRET 0x00050c0000000000000000000000000000000000000000000003ffffffffffff0000

2. To get the hexadecimal value for a clearance label, use atohexlabel with the -c option followed by the name of the clearance.

   $ atohexlabel -c SECRET 0x00050c0000000000000000000000000000000000000000000003ffffffffffff0000

To List a User's Home Directory SLDs and Their Labels

1. Assume the System Administrator role and go to an ADMIN_HIGH workspace.

2. Find the full pathname of the user's home directory MLD.

   % mldrealpath /home/janez /home/.MLD.janez/.SLD.3: % getlabel /home/.MLD.janez/.SLD.* /home/.MLD.janez/.SLD.0: [ADMIN_LOW] /home/.MLD.janez/.SLD.1: [CONFIDENTIAL] /home/.MLD.janez/.SLD.2: [TOP SECRET A B] /home/.MLD.janez/.SLD.3: [ADMIN_HIGH] /home/.MLD.janez/.SLD.4: [SECRET] /home/.MLD.janez/.SLD.5: [CONFIDENTIAL A B] /home/.MLD.janez/.SLD.6: [SECRET A B] /home/.MLD.janez/.SLD.7: [TOP SECRET] /home/.MLD.janez/.SLD.8: [UNCLASSIFIED]