Trusted Solaris Administrator's Procedures

Changing and Accessing Security Information (Tasks)

To Change the Allowed Number of Password Tries

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

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

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

Search for the string #RETRIES.

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

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

Save and close the file.

To Prevent Account Locking for Individuals

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

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.

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

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.

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

The Properties dialog displays.

Click the Trusted Solaris Attributes tab.

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

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

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

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.

Search for the string LOCK_AFTER_RETRIES.
LOCK_AFTER_RETRIES=yes

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

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.

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

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

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

Search for the string KEYBOARD_ABORT.
KEYBOARD_ABORT=disable

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.

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

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.

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

Save and quit the file.
:wq

To Change Configurable Kernel Switch Settings

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

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

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

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

Reboot the system for the values to go into effect.

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

Table 2-3 Configurable Trusted Solaris Switches in /etc/system


tsol_admin_high_to_cipso	The `tsol_admin_high_to_cipso` switch is not in the default `/etc/system` file, but it can be added if needed. The default setting in the kernel is 0. To enable communications with TSIX-type hosts that have the IP Label Field specified as CIPSO, this switch must be set to 1. This causes the label on a packet to be mapped to a valid CIPSO label with the highest classification and all compartments turned on, instead of being dropped. See "CIPSO Labels in Packets" for more information.
tsol_clean_windows	To support object reuse, the `tsol_clean_windows` switch is set to l by default, to clear inactive register windows on return from each system call. Setting the switch to 0 disables the cleaning of inactive windows after each system call, allowing the possibility that a system call can return kernel information from an inactive register window.
tsol_flush_buffers	Between the time when blocks are linked to an inode and written to disk, a crash could leave old disk blocks (possibly of a higher label) linked to a file system after fsck(1M) recovers the file system. To ensure that data blocks are flushed before inodes are updated on disk, the `tsol_flush_buffers` switch is set to 1 by default. There is a small performance penalty. Setting this switch to 0 disables the forced data flushing before inode updates.
tsol_hide_upgraded_names	Actions by users with the Upgrade File Label authorization and by processes with the `file_mac_write` and `file_upgrade_sl` privileges can either create a new file or subdirectory or relabel an existing file or subdirectory at a label that dominates the label of the containing directory. Such files and subdirectories are said to be upgraded and the names of the upgraded files and subdirectories are referred to as upgraded names. At sites that consider upgraded names to be sensitive information, the `tsol_hide_upgraded_names` switch enables the Security Administrator role to hide upgraded names. Setting this flag prevents getdents(2) from returning upgraded file names. Because all directory entries are examined before the results are returned, there is a performance penalty. Upgraded names display by default.
tsol_privs_debug	The `tsol_privs_debug` switch allows the administrative use of runpd(1M) to characterize a program`s use of privilege. See Chapter 13, Adding Software under "To Find Out Which Privileges a Program Needs" for the complete setup procedure. After the application(s) have been privileged debugged, this variable should be reset and the machine rebooted. Privilege debugging is disabled by default.

To Modify the Selection Configuration File

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

Go to the System_Admin folder in the Application Manager.

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.

Save the changes.

The settings go into effect at the next login.

To Add an Authorization to the Environment

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.

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

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.

Save and close the file.
:wq

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.

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.

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

Note -

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

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

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.

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.

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

A sample entry is below.
PRIV_RISKY = 90,

Save and close the file.

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.

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.

Save and close the file.

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

Note -

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.

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.

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

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

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

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]