7    Setting Up the Trusted System

This chapter lists the security-related tasks that must be completed after installation and before the trusted system is ready for general use, and refers to other chapters and to reference pages that explain how to accomplish the tasks.

7.1    Installation Notes

Before the enhanced authentication mechanism and other enhanced security features can be set up, the Tru64 UNIX installation or update must be completed and the optional enhanced security subsets (OSFC2SEC510 and OSFXC2SEC510) must be installed. If you plan to enable the password triviality checks, you also need to ensure that the OSFDCMTEXTxxx subset is installed.

The installation procedures for the optional security subsets are found in the Installation Guide.

After the security subsets are installed, you will see a message like the following:

Configuring "C2-Security " (OSFC2SEC510)
 
Configuring "C2-Security GUI " (OSFXC2SEC510)

The message refers to the installation process, not the security configuration and setup. The secconfig utility is used to configure or set up the enhanced authentication mechanism and ACLs. The audit subsystem is a kernel option and is set up with auditconfig.

7.1.1    Full Installation

A full installation of Tru64 UNIX (either advanced or basic) brings up the system with only a root accounts. Run the secconfig script before adding accounts.

7.1.2    Update Installation

If you are updating your system from previous version ofTru64 UNIX, all user accounts and databases are preserved, and running the secconfig program converts them to the enhanced security format.

7.2    Segment Sharing

Because of the page table sharing mechanism used for shared libraries, the normal file system permissions are not adequate to protect against unauthorized reading. For example, user joe has the following shared library:

-rw------- 2 joe staff 100000 Sep 18 1997 /usr/shlib/foo.so
 

When this shared library is used in a program, the text part of foo.so may be visible to other running processes even though they are not running as user joe. Only the text part of the library, not the data segment, is shared in this way.

To disable all segmentation and avoid any unauthorized sharing, answer "yes" when secconfig asks if you want to disable segment sharing. The secconfig script reports when segment sharing is already disabled.

Note

Disabling segment sharing can cause excessive memory use.

7.3    Installation Time Setup for Security

Enhanced security is included on CDE's Installation Checklist and can be configured at installation time. When you select Security, the secconfig utility is run to configure the enhanced authentication mechanism (enhanced security) and the ACL subsystem. The audit subsystem is configured as a kernel option. (Use the auditconfig utility to complete the setup of audit.)

If you are installing Tru64 UNIX from a console, you will find the audit subsystem listed as kernel configuration option. It can be selected and built into the kernel during the initial system configuration. (Use the auditconfig utility to complete the setup of audit.) Run the secconfig utility to configure the enhanced authentication mechanism and ACLs.

Use the following procedure to set up enhanced security on a new system.

  1. Verify that the enhanced security subsets (OSFC2SECxxx and OSFXC2SECxxx) are installed. If the subsets are not installed, install them, using the Installation Guide if you need more information.

  2. Log in as root.

  3. Run the interactive secconfig command and select ENHANCED security when prompted for a security level.

  4. Bring down your system to single user and reboot (your shutdown message should inform users of the impending password changes).

The auditconfig(8) reference page describes how to set up audit. The acl(4) reference page describes the ACL implementation and Section 11.3 describes the Tru64 UNIX ACL setup.

7.4    The secconfig Utility

The secconfig utility is an interactive program that allows you to toggle the security level on your system between BASE and ENHANCED. You can run the program while the system is in multiuser mode. However, depending on the security features chosen, when secconfig is complete, you may need to change the security features, you must reboot your system.

Before you can run secconfig, you must load the enhanced security subsets onto your system.

7.4.1    Setup Questions

Before configuring security, you need to be prepared to answer the following questions:

7.4.2    Invoking secconfig

Verify the security subset installation and invoke secconfig as follows:

# /usr/sbin/setld -i | grep SEC
OSFC2SEC510   installed   C2-Security (System Administration)
OSFXC2SEC510  installed   C2-Security GUI (System Administration)
 
# sysman secconfig
 
# shutdown -r now

7.5    Configuring Security Features

You can configure security features individually or you can enable all the security features.

7.5.1    Configuring Audit

You can run the audit subsystem without installing the security subsets. Configure the Audit Subsystem kernel option and then run the auditconfig utility to configure audit. The auditconfig utility includes the kernel build procedures. See the auditconfig(8) and doconfig(8) reference pages for more information.

7.5.2    Configuring ACLs

You can run the ACL subsystem without installing the optional enhanced security subsets. ACL processing is now dynamically enabled and disabled using the sysconfig command or the secconfig utility. See the sysconfig(8) reference page and Section 11.3 for more information.

7.5.3    Configuring Enhanced Authentication with NIS

Running the secconfig command creates an enhanced user profile for each user on the system. If the user accounts are local, the passwords are expired and the users must enter a new password the next time they log in.

If the machine has a password database served by NIS (Network Information Service), secconfig asks if you want to create a local enhanced authentication profile for each user in the NIS server password database. If you do, see Chapter 9 for a description of how to distribute the enhanced authentication database with NIS. Subsequent changes in NIS passwords are not propagated to the database. The enhanced passwords now on the local machine are expired and users must enter a new password the next time they log in.

If you change the security level back to BASE security, the enhanced authentication profile files are left in place. When you return to ENHANCED security, as long as there is an enhanced authentication profile file and it contains a password, the enhanced password is updated.

You can use the edauth utility to view specified databases.

7.5.4    Authentication Features Configuration

Enhanced security provides the ability to specify system default values that apply to users, terminals, and devices. Thus, an administrator is not required to replicate values when they are all the same. The following sections briefly describe some common defaults and how you can configure them. The system defaults are stored in the default database at /etc/auth/system/default.

This database can contain four types of fields:

The dxaccounts GUI can modify the default fields for users by going to Local Templates-->Default. The dxdevices GUI can modify the default fields for devices. The edauth utility provides a lower-level interface to all of the default fields.

See the authcap(4) reference page for a description of the file format and field values, the edauth(8) reference page for use of edauth, and the default(4), prpasswd(4), ttys(4), and devassign(4) reference pages for complete descriptions of the various fields and an interpretation of values.

7.5.4.1    Aging

If you do not want password aging on your system, in the default database set u_exp and u_life to 0, and then (because of the way the default methods of determining length restrictions on passwords work based on the password lifetime) also set u_minchosen and u_maxchosen to appropriate values for the site.

An example entry could be as follows:

	:u_exp#0:u_life#0:u_minchosen#5:u_maxchosen#32:\
 

7.5.4.2    Minimum Change Time

You can remove the minimum change time interval by setting the u_minchg field to 0 as follows:

	:u_minchg#0:\

This allows users to immediately change their password after a previous password change.

7.5.4.3    Changing Controls

The password-changing controls can be configured to your site's needs. By putting the following fields in the default database, you allow users to select how their passwords are chosen:

	:u_pickpw:u_genpwd:u_genchars:u_genletters:u_restrict:\
	:u_policy:u_nullpw:u_pwdepth#0:\

(Of those, u_pwdepth is numeric and the rest are Boolean. A Boolean field is true if it is specified and false if it is followed by an @.)

7.5.4.4    Maximum Login Attempts

In breakin detection, consective login failures are counted and compared to a maximum for a user (u_maxtries) or for a terminal (t_maxtries). If the maximum is exceded, then logins to the user account or the terminal are disabled for a time period specified by u_unlock or t_unlock. To disable breakin evasion for user accounts, set u_maxtries to 0. To disable for terminals, set t_maxtries to 0. The default database entry for users would be as follows:

	:u_maxtries#0:\

7.5.4.5    Time Between Login Attempts

If the default evasion time (86400 seconds or 24 hours) is not appropriate for your site, change the u_unlock field to an appropriate value for your site (number of seconds before a success is recognized after the last failure, once the u_maxtries limit is reached). Setting the u_unlock field to 0 (:u_unlock#0:) sets the time between log in attempts to infinity (no automatic reenabling occurs). The equivalent behavior for terminals is controlled by t_maxtries.

7.5.4.6    Time Between Logins

You can set system wide maximum allowable time between log ins in the u_max_login_intvl field of the default database.

The system default log in timeout for terminals can be changed in the t_login_timeout field of the default database. It can also be set in the * entry of the ttys database. This field should be 0 (infinite) for X displays.

7.5.4.7    Per-Terminal Login Records

If you do not want to record per-terminal log in successes and failures, set the d_skip_ttys_updates Boolean field in the default database as follows:

	:d_skip_ttys_updates:\
 

This has the sideeffect of disabling any further per-terminal breakin evasion.

7.5.4.8    Successful Login Logging

Strict C2 security requires the logging of successful logins. To disable this logging, set the d_skip_success_login_log Boolean field as follows:

	:d_skip_success_login_log:\

7.5.4.9    Failed Login Logging

Failed login attempts to user accounts are normally recorded. To disable this logging, which also disables breakin detection and evasion system wide, set the d_skip_fail_login_log Boolean field as follows:

	:d_skip_fail_login_log:\
 

7.5.4.10    Automatic Enhanced Profile Creation

Setting the d_auto_migrate_users Boolean field allows the creation of enhanced profiles at login time if they are missing, so that traditional methods of adding user profiles can be used without change.

7.5.4.11    Vouching

You can set the d_accept_alternate_vouching field to allow enhanced security and DCE to work together.

7.5.4.12    Encryption

If you want the user passwords to stay in the /etc/passwd file to support programs that use crypt() to do password validation, but still want to use other features of enhanced profiles, put the following entry in the default database before running secconfig:

	:u_newcrypt#3:\

This corresponds to the AUTH_CRYPT_C1CRYPT value from the <prot.h> file.

7.6    System Administrator Tasks

On a Tru64 UNIX system the root account is used to perform both system administration and ISSO tasks. The system administrator traditionally performs the following tasks using the Account Manager (dxaccounts) program:

See Chapter 9 and the dxaccounts(8) reference page for more information.

7.7    ISSO Tasks

On a Tru64 UNIX system the root account is used to perform both system administration and ISSO tasks. The ISSO traditionally performs the tasks described in the following sections using the Account Manager (dxaccount program).

7.7.1    Check System Defaults

The ISSO checks that the following general defaults and account defaults conform to the site's security policy:

7.7.2    Modifying a User Account

The ISSO modifies the accounts of any users who have fewer restrictions or more restrictions than the defaults.

If users' accounts are locked by default when they are created, you need to unlock the accounts before users can login. Depending on the procedures established at your site, you may want to unlock all accounts when created or unlock them when the users are ready to login for the first time.

See Chapter 9 for more information.

7.7.3    Assigning Terminal Devices

Use the dxdevices program to perform the following device-assignment tasks:

If terminal devices are locked by default, you need to unlock them before users can login.

See Chapter 8 and the dxdevices(8) reference page for more information.

7.7.4    Setting Up Auditing

The ISSO performs the following tasks to set up the audit system:

See Chapter 10 for more information.

7.8    Backing the System Up

Make a backup copy of the root file system as a precaution. All the files that have been modified during system setup will be copied.

The backup can be made by using one of the following commands (dump only works on UFS file systems):


# dump -0uf /dev/rmt0h /

or

# vdump -0Nuf /dev/rmt0h /

Substitute the appropriate tape device for your system.