6 Introduction for Administrators

The Digital UNIX operating system and its commands, utilities, and subsystems have all been modified to produce the system's trusted computing base (TCB). The changes to the system result in a system that meets the C2 security requirements defined in the Orange Book.

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 Digital UNIX 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 Digital 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 Digital 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 trusted system 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 Digital 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 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 Digital 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 Digital 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 Digital 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

Threat	Effect
Data disclosure	The threat of disclosure occurs when a user gains access to information for which that user does not have a need-to-know. Need-to-know restrictions are enforced by the system's discretionary access control features, which enable users, at their own discretion, to allow their information to be accessed by other users.
Loss of data integrity	The threat of integrity loss occurs when user or system information is overwritten - either intentionally or inadvertently. Loss of data integrity can occur from hardware failures (for example, disk track failures) or software failures. When a loss of data integrity occurs, an opportunity is created for an unauthorized user to change information that affects the ability of the system to function properly.
Loss of TCB integrity	The TCB enforces the system's security policy. Any loss of integrity of TCB programs and files, including the executable copies of those programs in memory, constitutes a compromise of the integrity of the TCB itself and can lead to incorrect enforcement of the security policy.
Denial of service	To function usefully, the system must respond to requests for service. One way to compromise the usefulness of a system is to cause it to fail in its ability to process work. When denial of service occurs, users lose the ability to access their information. Depending upon the method of attack, the threat of denial of service can accompany any of the other previously mentioned threats.

6.3 Enhanced Security Features

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

6.3.1 Audit Features

Digital 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 from the command line and maintained from the command line or with OSF/Motif based interfaces.

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
- 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 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. The time before the password expiration warnings is only a default value, and cannot be changed on a per profile 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, Digital 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. Digital'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.4 Windows-Based Administration Utilities

Note
The functions previously performed with the XIsso and XSysAdmin programs have been moved to other graphical user interfaces (GUIs). The XIsso and XSysAdmin programs in this release are only interfaces to the other GUIs and support for XIsso and XSysAdmin will be discontinued after this release.

The following three window-based 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 in the DECwindows environment 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: You use dxaudit to configure the audit system mask and reports, and use dxaccounts to set a user's audit mask and controls. Administrators have the flexibility to configure the audit subsystem without the requirement of installing additional C2 security features.

: You can find the Audit Manager GUI under the CDE Application Manager->System_Admin-> System_Management_Utilities->Daily_Admin->Audit Manager. If you are using DECwindows environment, start the Audit Manager from the command line with the /usr/tcb/bin/dxaudit command.

dxdevices: You use the dxdevices program to configure devices. In both the CDE and DECwindows environment, the Devices GUI is started from the command line with the /usr/tcb/bin/dxdevices 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 (OSFC2SEC400 and OSFXC2SEC400) 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 secsetup command, you can select the C2 security features appropriate for your system. The secsetup utility is found in CDE under Application Manager->System_Admin->System_Managent_Utilities->Configuration-> Security. The secsetup utitlity can also be run from the command line, which is the way it must be run in the DECwindows environment.

The audit subsystem is configurable at kernel link time, regardless of the security level of the system. 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 configured at install time and are enabled and disabled using the secsetup utility.

6.5 Administrating the Trusted Operating System

An administrator of a trusted Digital UNIX 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 Digital 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.

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	Major Responsibilities
Information Systems Security Officer	Sets system defaults for users, maintains security-related authentication profile parameters, modifies user accounts, administers the audit subsystem, assigns devices, and ensures system integrity.
System administrator	Creates user accounts, creates and maintains file systems, and recovers from system failures.
Operator	Administers line printers, mounts and unmounts file systems, and starts up and shuts down the system.

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.

On a trusted Digital 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 the ISSO. The trusted Digital UNIX system does not support sysadmin and isso accounts.

6.5.1.1 Responsibilities of the Information Systems Security Officer

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.)
Assigns systemwide defaults. Establishes defaults for user login controls and password parameters. (See Chapter 9.)
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 (or DECwindows 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 (for example, default command authorizations) 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 (for example, to increase authorizations and privileges). 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 (or the DECwindows 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 and command authorization enforcement within a protected subsystem. Administration of these includes assigning subsystem-related authorizations, 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 Digital 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

Database	Location	Contents
Protected password	`/tcb/files/auth.db`	User authentication database
System defaults	`/etc/auth/system/default`	Default values for database fields
Terminal control	`/etc/auth/system/ttys.db`	Security information about each terminal
File control	`/etc/auth/system/files`	Protection attributes of each system file
Device assignment	`/etc/auth/system/devassign`	Device-specific controls

6.5.2.1 Protected Password Database

The protected password database stores the 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 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 extended profile 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 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

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 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 pathname can refer to the same physical device. For example, two pathname 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 for details