6    Introduction for Administrators

The Tru64 UNIX operating system with the optional enhanced security subsets installed can be configured to meet the C2 security requirements as defined in the Orange Book. When the enhanced security subsets are installed and configured to meet C2 security requirements, the system is referred to as a trusted system. This chapter defines a trusted system and the requirements that the system was designed to satisfy. It introduces the terms and security concepts that are fundamental to system security, and it summarizes the major features of the system security policy enforced by the trusted system. This chapter also summarizes the major characteristics of the system, including its primary databases, subsystems, resource configuration files, and outlines the administrative roles and functions necessary to maintain a trusted system.

6.1    Frequently Asked Questions About Trusted Systems

When considering the use of a trusted system, some important questions are frequently asked:

• What is the performance impact of running a trusted system? Users are often concerned that enhancing a system's security features will hinder its usability by slowing down processing.

• Will a trusted system unnecessarily restrict an ordinary user's ability to accomplish their work?

• Can any UNIX system, including Tru64 UNIX, be secure? Users are sometimes skeptical that a system that has a reputation for being easy to penetrate can be used as the basis for a trusted system.

Although the trusted system has extended the Tru64 UNIX operating system to enforce additional security checks, the basic mechanisms of the system remain the same. Compatibility at the binary program interface and at the user interface have been design criteria for the trusted system. The trust enhancements have been made to incur as small a reduction in performance and as little unexpected system behavior as possible.

Although users will see few differences, the additional security requirements do add overhead for the administrative staff. Not only must this staff be familiar with the tasks involved in administering a trusted system, they must also be familiar with the trusted system mechanisms so they can understand the implications of their actions.

A knowledgeable administrative staff contributes to the security of any site. In fact, training both the administrative staff and the users is one of the best ways you can protect the system against penetration.

6.2    Defining a Trusted System

A trusted system is one that employs sufficient hardware and software integrity measures to allow its use for simultaneously processing a range of sensitive or confidential information. A trusted system can be trusted to perform correctly in two important ways:

• The system's operational features - in particular, its application interface - operate correctly and satisfy the computing needs of the system's users.

• The system's security features enforce the site's security policy and offer adequate protection from threats.

A security policy is a statement of the rules and practices that regulate how an organization manages, protects, and distributes sensitive information. The system's security mechanisms maintain full compatibility with existing Tru64 UNIX security mechanisms while expanding the protection of user and system information.

An organization carries out its security policy by running the system as described in this manual and by adhering to the administrative and procedural guidelines defined for the system.

Understanding the concept of a trusted computing base (TCB) is important to understanding a trusted system. The TCB is the set of protection mechanisms that enforces the system's security policy. It includes all of the code that runs with hardware privilege (that is, the kernel) and all code running in processes that cooperate with the operating system to enforce the security policy. The system's TCB consists of the following parts:

• A modified Tru64 UNIX kernel. The kernel runs in the privileged execution mode of the system's CPU. The trusted system's kernel is isolated from the rest of the system because it runs in a separate execution domain - the processor's protected supervisor state.

• Trusted commands and utilities. The system corrects, modifies, and adds to the Tru64 UNIX software.

A TCB is typically defined in terms of subjects and objects. The TCB oversees and monitors interactions between subjects (active entities such as processes) and objects (passive entities such as files, devices, and inter-process communication mechanisms). See Appendix A for the software part of the system's TCB.

The trusted system protects a Tru64 UNIX system and its users against a variety of threats and system compromises. The most important of these threats are summarized in Table 6-1.

Table 6-1:  Potential System Threats

6.3    Enhanced Security Features

The Tru64 UNIX operating system, with the optional enhanced security subset installed and in use, is designed to meet or exceed the requirements of the C2 evaluation class of Department of Defense 5200.28-STD as described in the Orange Book. The audit and ACL features can be enabled without the optional enhanced security subsets installed. The enhanced password features require the enhanced security subset to be installed.

6.3.1    Audit Features

Tru64 UNIX provides the following audit features:

• The ability to send audit logs to a remote host

• The following types of event auditing:

  • Site-defined support

  • System call support

  • Habitat support

  • Application support

• Fine-grained preselection of system events, application events, and site-definable events

• Extensive postreduction of system events, application events, and site-definable events

• Link-time configurability of the audit subsystem

• A per user audit characteristics profile (with enhanced I and A)

• OSF/Motif based interfaces

The audit system is set up using the audit configuration utility and maintained from the command line or with the dxaudit GUI.

6.3.2    Identification and Authentication (I and A) Features

Enhanced security provides the following I and A features:

• Password control

  • Configurable password length, up to 80 characters maximum.

  • Configurable password lifetimes. This includes an optional minimum interval between password changes.

  • A dynamic minimum password length, based directly on the Department of Defense Password Management Guideline (Green Book) guidelines and the password lifetime or a minimum length set by the system administrator.

  • Per-user password generation flags, which include the ability to require a user to have a generated password.

  • Recording of who (besides the user) last changed the user's password.

  • Configurable password usage history (0-9 previously used passwords).

• Login control

  • Optional recording of last terminal and time of the last successful login, and of the last unsuccessful login attempt.

  • Automatic account lockout after a specified number of consecutive bad access attempts. In cases of system database corruption, root can still log into the console (/dev/console).

  • A per-terminal setting for delay between consecutive login attempts, and the maximum amount of time each attempt is allowed before being declared a failed attempt.

  • A per-terminal setting for maximum consecutive failed login attempts before locking any new accesses from that terminal.

• Ownership for pseudoaccounts. This allows a way to differentiate auditable users when two /etc/passwd entries share a UID, such as uucp and uucpa.

• A notion of whether the account is "retired" or "locked." These are fundamentally the same as far as granting access is concerned, but are different administratively. There is also a provision for the auto-retirement of accounts by recording an expiration on the account itself.

• System default values for the various I and A fields. Most default values can be overridden on a per user basis. However, some values such as the password expiration warning time are system-wide and cannot be changed on a per user basis.

6.3.3    Access Control Lists (ACLs)

Traditionally, UNIX systems control a user's access to files and directories (file system objects) using a method of discretionary access control (DAC) normally referred to as the permission bits. By default, Tru64 UNIX systems are run using this untrusted method of DAC for file system objects.

ACLs provide greater granularity of file system object protection than the default DAC protection. The level of file system object protection provided by ACLs is required by trusted systems, but ACLs can be enabled separately from the other security options. This allows you to tailor your system to use only the security options that you need, instead of having to setup a fully trusted system.

6.3.4    Integrity Features

The enhanced security option provides the capability to validate the correct operation of hardware, firmware, and software components of the TCB. The firmware includes power-on diagnostics and more extensive diagnostics that can optionally be enabled. The firmware itself resides in EEPROM memory and can be physically write-protected. It can be compared with, or reloaded from, an off-line master copy. Compaq's service engineers can run additional hardware diagnostics as well.

The firmware can require authorization to load any operating software other than the default, or to execute privileged console monitor commands that examine or modify memory.

Once the operating system has been loaded, you can run system diagnostics that validate the correct operation of the hardware and software. In addition, test suites are available to ensure the correct operation of the operating system software.

You can use the following tools to detect inconsistencies in the TCB software and databases:

fverify

The fverify program reads subset inventory records from standard input and verifies that the attributes for the files on the system match the attributes listed in the corresponding records. Missing files and inconsistencies in file size, checksum, user ID, group ID, permissions, and file type are reported.

authck

The authck program checks both the overall structure and internal field consistency of all components of the authentication database. It reports all problems it finds.

6.3.5    Security db Utilities

A customized version of the Berkeley Database (Berkeley DB) is embedded in Tru64 UNIX to provide high-performance database support for critical security files. The DB includes full transactional support and database recovery, using write-ahead logging and checkpointing to record changes. In the event of catastrophic failure, the security database can be restored to its last transaction-consistent state by restoring the database files and rolling the log forward.

The following database management utilities are included with Enhanced Security:

db_archive

Displays the enhanced security database log files no longer involved in active transactions that can safely be backed up and deleted to regain space on /var.

db_checkpoint

Flushes memory, writes a checkpoint record to the log and flushes the log to disk.

db_load

Reads from a file or standard input and loads into a database.

db_unload

Unloads the database into a file.

db_stat

Displays the security database statistics.

db_recover

Restores the database to a consistent state after an unexpected failure.

In general, the security database is loaded or unloaded only by installation utilities. While the database has been designed to minimize database administration tasks, the addition of security database log files does present the possibility of log files expanding to fill /var. Thus, the security configuration utility includes an option that creates a cron job to periodically delete log files no longer involved in active transactions.

6.4    Graphical Administration Utilities

The following graphical utilities help you deal with the day-to-day security administration on your local machine:

dxaccounts

The Account Manager in the Common Desktop Environment (CDE) or the dxaccounts program from the command line allows you to create and modify all user accounts, and to modify the system defaults. You can find the Account Manager under the Application Manager --> System_Admin --> System_Management_Utilities --> Daily_Admin --> Account Manager.

dxaudit

Use the dxaudit GUI to manage the audit system mask of events to audit. It can also be used to generate audit reports. The dxaccounts GUI can set a per user audit mask. Administrators have the flexibility to configure the audit subsystem without the requirement of installing additional security features.

You can find the Audit Manager GUI under the CDE Application Manager --> System_Admin --> System_Management_Utilities --> Daily_Admin --> Audit Manager. The Audit Manager can also be started from the command line with the /usr/tcb/bin/dxaudit command.

dxdevices

Use the dxdevices program to configure devices. The Devices GUI is started from the command line with the /usr/tcb/bin/dxdevices command.

dxsetacl

Use the dxsetacl program to view and set ACLs on files and subdirectories. The Devices GUI is started from the command line with the /usr/tcb/bin/dxsetacl command.

For more details about starting the GUIs from the command line, see the dxaccounts(8), dxaudit(8), and dxdevices(8) reference pages.

6.4.1    Installing and Configuring Enhanced Security

Before security can be configured, the enhanced security subsets (OSFC2SEC510 and OSFXC2SEC510) must be installed on your system. See the Installation Guide for more information.

System administrators can select the optional C2 security features that are required for their system. You do not have to configure all the features. The default security level consists of object reuse protection, traditional UNIX passwords, and discretionary access control; by running the secconfig command, you can select the security features appropriate for your system. The secconfig utility is found in CDE under Application Manager --> System_Admin --> System_Managent_Utilities --> Configuration --> Security. The secconfig utitlity can also be run from the command line.

The audit subsystem is configurable at kernel link time, regardless of the security level of the system. Auditing is initially configured using the sysman auditconfig utility. The identification and authorization (I and A) features are configured at boot time, so that the system administrator can configure the security level of the system. ACLs are enabled and disabled using the secconfig utility or the sysconfig command.

6.5    Administrating the Trusted Operating System

An administrator of a trusted system is responsible for overseeing many additional security functions such as the following:

• Setting up security databases

• Monitoring the security and integrity of the system

• Auditing security-related events and maintaining the system's audit functions

• Performing miscellaneous administrative tasks associated with protected subsystems

6.5.1    Traditional Administrative Roles

An important difference between a nontrusted and a trusted Tru64 UNIX system is in the area of system administration. An effective administrator must understand the system's security policy, how it is controlled by the information entered into the system's security databases, and how any changes made in these databases affect user and administrator actions.

Note

On a trusted systemTru64 UNIX, the traditional security administrative roles may be performed by the same person. Trusted Tru64 UNIX does not support sysadmin and isso accounts. An administrator logged in as root can use the dxaccounts, dxaudit , and dxdevices interfaces to set up, modify, and maintain accounts and administer the security aspects of the system.

Administrators must be aware of the sensitivity of the information being protected at a site - the degree to which users are aware of, willing, and able to cooperate with the system's security policy, and the threat of penetration or misuse from insiders and outsiders. Only vigilance and proper use of the system can keep the system secure.

Table 6-2 summarizes these major roles and their associated responsibilities in the system. The sections that follow describe these responsibilities in greater detail.

Table 6-2:  Traditional Administrative Roles

Role association, coupled with sophisticated auditing features, enables a site to maintain accountability for administrative actions. This helps to prevent security problems and makes other problems easier to identify and solve.

6.5.1.1    Responsibilities of the Information Systems Security Officer

Note

On a trusted Tru64 UNIX system, responsibility for all of these traditional roles can be assumed by one person. An administrator with root privilege can perform any of the duties usually assigned to an ISSO.

The information systems security officer (ISSO) is primarily responsible for managing security-related mechanisms. The ISSO controls the way that users log in and identify themselves to the system. The ISSO must cooperate with the system administrator when performing security-related tasks; the system's checks and balances often require that each perform a separate part of a total task (for example, account creation). The following list describes specific ISSO responsibilities:

• Performs device assignment. Assigns devices (terminals, printers, and removable devices, such as floppy disk and magnetic tape). Specifies the appropriate operational parameters for these devices. (See Chapter 8.)

• Modifies user accounts. After accounts have been established by the system administrator, sets up authentication profiles reflecting the level of trust placed in those users. (See Chapter 9.)

• Audits system activity. Selects the security-relevant events that are to be audited by the system. Enables and disables auditing, sets audit parameters, produces reports, and regularly reviews audit data. (See Chapter 10.)

• Ensures system integrity. Ensures the integrity of the system by periodically running the authck program to check the integrity of the security databases and files critical to the correct operation of the system. (See the authck(8) reference page and Chapter 12.)

All of the ISSO functions, except integrity checking, can be performed using the Account Manager (dxaccounts interface). To perform ISSO functions, you must have root privileges and be logged on as root.

6.5.1.2    Responsibilities of the System Administrator

The system administrator is primarily responsible for account creation and disabling, and for ensuring the internal integrity of the system software and file systems. The system administrator also shares with the ISSO the responsibility for day-to-day user account maintenance.

The following list describes specific system administrator responsibilities:

• Creates user accounts. All accounts created by the system administrator have the default characteristics established by the ISSO for the system. Once an account has been created, the ISSO can modify that account, changing individual users' authentication profiles as appropriate. (See Chapter 9.)

• Creates groups. Creates new groups as part of user account creation. These groups are used by the system's discretionary access control mechanism. (See Chapter 9.)

• Modifies ISSO accounts. As an additional system security feature, the ISSOs are not authorized to modify their own authentication profiles .Instead, the system administrator performs this function. (See Chapter 9.)

• Creates file systems. Creates and maintains file systems by running programs such as newfs and fsck. See the System Administration manual and the newfs(8) and fsck(8) reference pages for details.

• Restores the system files and users' files in the event of accidental deletion.

The system administrator creates user accounts and creates groups with the Account Manager (dxaccounts) interface.

To perform system administration functions, you must have root privileges and be logged on as root.

6.5.1.3    Responsibilities of the Operator

The operator is primarily responsible for ensuring that day-to-day hardware and software operations are performed in a trusted fashion.

The following list describes some specific operator responsibilities:

• Administers line printers. Enables and disables printers and performs other printer maintenance operations.

• Starts and shuts down the system. Boots the system, changes system run levels, and halts the system, when necessary.

• Mounts and unmounts file systems.

• Performs backups and file restorations.

To perform the operator functions, you must have root privileges and be logged on as root.

6.5.2    Protected Subsystems

Protected subsystems are collections of programs and resources that are grouped together by function and are important pieces of the TCB. They may or may not need privileges to accomplish their function. The system provides mechanisms for unified auditing within a protected subsystem. Administration of the includes performing subsystem administration tasks, and assuring proper installation and continued operation of the subsystem.

The components of a protected subsystem are protected with the group ID of the group allowed access rights to the programs and data in the subsystem. The only way for a user to access the subsystem information is by running programs in the subsystem.

The subsystem programs are set-group-ID (SGID) on execution to the subsystem's group. This method is also used in untrusted Tru64 UNIX systems. All of the subsystems have been modified to meet security and accountability requirements.

The system provides common mechanisms for implementing all of the protected subsystems, including the following:

• Ensuring that the subsystem databases are not corrupted

• Enforcing isolation between users

• Producing audit records

Table 6-3 summarizes the protected subsystems.

Table 6-3:  Protected Subsystems

6.5.2.1    Enhanced (Protected) Password Database

The protected password database stores the enhanced authentication profile for each user who has an account on the system. Each profile contains information such as the following:

• User name and ID

• Encrypted password

• User's audit characteristics

• Password generation parameters

• Successful and unsuccessful login times and terminals

The enhanced (protected) password database is located in the file /tcb/files/auth.db.

See the prpasswd(4) reference page for more information on the contents of the enhanced password database.

6.5.2.2    System Defaults Database

The system defaults database stores default values for database fields. These defaults are used when the administrator does not set explicit values in the enhanced (protected) password database, terminal control database, or device assignment database.

The system defaults database contains information such as the following:

• Default password generation parameters

• Default number of unsuccessful login attempts allowed per user

• Default number of unsuccessful login attempts allowed per directly connected terminal

• Default device assignment parameters

More information on the contents of the system defaults database located in /etc/auth/system/default can be found in the default(4) reference page.

6.5.2.3    Terminal Control Database

The terminal control database contains information that the administrator uses to control login activity at each terminal attached to the system. The system uses this database as an aid in controlling access to the system through terminals. The administrator can set different policies for logins at different terminals, depending upon the site's physical and administrative needs.

Each entry in the terminal control database contains information such as the following:

• Terminal device name

• User ID and time stamp of the last successful login attempt from this terminal

• User ID and time stamp of the last unsuccessful login attempt from this terminal

• Delay imposed between login attempts from this terminal

• Number of unsuccessful attempts that can be made before locking this terminal

When the system is installed, the terminal control database contains an entry for the system console. The ISSO modifies these initial values during system setup. A corresponding entry, also initially installed, is required in the device assignment database before logins are allowed.

For more information about the contents of the terminal control database located in /etc/auth/system/ttys.db, see the ttys(4) reference page. Procedures for adding terminals are described in Chapter 8.

6.5.2.4    File Control Database

The file control database contains information about the protection attributes of system files (that is, files important to the TCB's operation). This database helps maintain the integrity of the TCB. It contains one entry for each system file.

Each entry in the file control database contains the following information:

• Full pathname of the file

• File owner and group

• File mode and type

• Potential and granted privilege sets

• Access control list

When the system is installed, the file control database contains entries for all security relevant system files. The ISSO does not need to modify this database during system setup and rarely needs to update it during system operation. Chapter 12 describes how to check the integrity of the database and modify it if necessary.

For more information about the contents of the file control database located in /etc/auth/system/files, see the files(4) reference page.

6.5.2.5    Device Assignment Database

The device assignment database contains information about devices that are used to exchange data with users. Each login terminal ž .\" , a printer device, or an import/export .\" .NX R "import and export" .\" device Ÿmust have an entry in the device assignment database. The system uses this database as an aid in restricting the security attributes of data that can be sent or received through the system's devices.

Each entry in the device assignment database contains information that describes a device and that relates the device pathname to the appropriate physical device. This is necessary because a number of distinct pathnames can refer to the same physical device. For example, two pathnames can refer to the same serial port - one with modem control enabled and the other with modem control disabled.

Each entry in the device assignment database contains information such as the following:

• Device pathname

• Other pathnames referencing the same physical device

• Device type

Entries referring to login terminals must have corresponding entries in the terminal control database.

The device assignment database is located in /etc/auth/system/devassign. See the devassign(4) reference page and Chapter 8for details

6.6    Enhanced Security in a Cluster Environment

All the features of Tru64 UNIX enhanced security are available in a cluster environment. In some cases the setup and configuration is different than a noncluster environment. The security configuration procedure is also different depending whether enhanced security is being enabled on an already running cluster or whether the cluster is being installed. In all cases, enhanced security runs across all machines in the cluster and is seen as a single enhanced security environment also known as a common security domain. See Appendix G for more information on enhanced security in a cluster.

6.6.1    Installation Time Configuration

If you are installing the operating system on the first member of cluster, you need to completely set up your security environment before installing the TruCluster Server software. The security configuration, as well as other configuration data, will be propogated to other members as they come up. Chapter 7 explains how to set up enhanced security on a system not in a cluster.

If you are installing the operating system on member of cluster other than the first system, the enhanced security environment will be inherited from the existing systems in the cluster when the TruCluster software is installed. Chapter 7 explains how to set up enhanced security on a system not in a cluster.

6.6.2    Postinstallation Configuration

If you are enabling enhanced security on systems already running in a cluster environment, you need to setup enhanced security from a single machine and then reboot every machine in the cluster.