[ Previous | Next | Contents | Glossary | Home | Search ]
AIX Version 4.3 System Management Guide: Operating System and Devices

Trusted Computing Base Overview

The Trusted Computing Base (TCB) is the part of the system that is responsible for enforcing the information security policies of the system. All of the computer's hardware is included in the TCB, but a person administering the system should be concerned primarily with the software components of the TCB.

Many of the TCB functions are now optionally enabled at installation time. Selecting yes for the Install Trusted Computing Base option on the Installation and Settings menu enables the trusted path, trusted shell, and system integrity checking (tcbck command). Selecting no disables these features. These features can only be enabled at installation time.

The TCB software consists of:

Most system files are accessible only by the root user; however, some can also be accessed by members of an administrative group. Only the root user can alter the operating system kernel. The TCB contains the following trusted programs:

In the operating system, the person who administers the system can mark trusted files as part of the Trusted Computing Base (the chtcb command), so that they can be clearly distinguished.

The person who administers the system must be careful to add only software that can be fully trusted to the TCB. Consider trusting software if, for example:

The system administrator must determine how much trust can be given to a particular program. This determination should include considering the value of the information resources on the system in deciding how much trust is required for a program to be installed with privilege.

Checking the Trusted Computing Base

The tcbck command audits the security state of the Trusted Computing Base. The security of the operating system is jeopardized when the TCB files are not properly protected or when configuration files have unsafe values. The tcbck command audits this information by reading the /etc/security/sysck.cfg file. This file includes a description of all TCB files, configuration files, and trusted commands.

Note: If the Install Trusted Computing Base option was not selected during the initial installation, the tcbck command will be disabled. The command can be properly enabled only by reinstalling the system.

Using the tcbck Command

The tcbck command is normally used to:

The tcbck command can be used in three ways:

Checking Trusted Files

You should run the tcbck command to check the installation of trusted files at system initialization. To perform this automatically and produce a log of what was in error, add the following command to the /etc/rc file:

tcbck -y ALL

This causes the tcbck command to check the installation of each file described by the /etc/security/sysck.cfg file.

Checking the File System

You should run the tcbck command to check the file system any time you suspect the integrity of the system may have been compromised. This is done by issuing the following command:

tcbck -t tree

When the tcbck command is used with the tree parameter, all files on the system are checked for correct installation (this could take a long time). If the tcbck command discovers any files that are potential threats to system security, you can alter the suspected file to remove the offending attributes. In addition, the following checks are performed on all other files in the file system:

Note: All device entries must have been added to the /etc/security/sysck.cfg file prior to execution of the tcbck command or the system is rendered unusable. Use the -l option to add trusted devices to /etc/security/sysck.cfg.

Adding a Trusted Program

To add a specific program to the /etc/security/sysck.cfg file, use the following command:

tcbck -a PathName [attribute=value]

Only attributes whose values can or should not be deduced from the current state of the file need be specified on the command line. All attribute names appear in the /etc/security/sysck.cfg file.

For example, the following command registers a new setuid-root program named /usr/bin/setgroups, which has a link named /usr/bin/getgroups:

tcbck -a /usr/bin/setgroups links=/usr/bin/get

After installing a program, you may not know which new files should be registered in the /etc/security/sysck.cfg file. These can be found and added with the following command:

tcbck -t tree

This command displays the name of any file that should be registered in the /etc/security/sysck.cfg file.

Deleting a Trusted Program

If you remove a file described in the /etc/security/sysck.cfg file, you should also remove the description of this file. For example, if you have deleted the /etc/cvid program, the following command will cause an error message to be shown:

tcbck -t ALL

The error message shown is:

3001-020 The file /etc/cvid was not found.

The description of this program can be removed with the following command:

tcbck -d /etc/cvid

Configuring the tcbck Program

The tcbck command reads the /etc/security/sysck.cfg file to determine which files to check. Each trusted program on the system should be described by a stanza in the /etc/security/sysck.cfg file.

Each stanza has the following attributes:

class Name of a group of files. This attribute allows several files with the same class name to be checked by specifying a single argument to the tcbck command. More than one class can be specified, with each class being separated by a comma.
owner User ID or name of the file owner. If this does not match the file owner, the tcbck command sets the owner ID of the file to this value.
group Group ID or name of the file's group. If this does not match the file owner, the tcbck command sets the owner ID of the file to this value.
mode Comma-separated list of values. The allowed values are SUID, SGID, SVTX, and TCB. The file permissions must be the last value and can be specified either as an octal value or as a 9-character string. For example, either 755 or rwxr-xr-x are valid file permissions. If this does not match the actual file mode, the tcbck command applies the correct value.
links Comma-separated list of path names linked to this file. If any path name in this list is not linked to the file, the tcbck command creates the link. If used without the tree parameter, the tcbck command prints a message that there are extra links but does not determine their names. If used with the tree parameter, the tcbck command also prints any additional path names linked to this file.
symlinks Comma-separated list of path names symbolically linked to this file. If any path name in this list is not a symbolic link to the file, the tcbck command creates the symbolic link. If used with the tree argument, the tcbck command also prints any additional path names that are symbolic links to this file.
program Comma-separated list of values. The first value is the path name of a checking program. Additional values are passed as arguments to the program when it is executed.
Note: The first argument is always one of -y, -n, -p, or -t, depending on which flag the tcbck command was used with.
acl Text string representing the access control list for the file. It must be of the same format as the output of the aclget command. If this does not match the actual file ACL, the sysck command applies this value using the aclput command.
Note: Note that the attributes SUID, SGID, and SVTX must match those specified for the mode, if present.
source Name of a file this source file is to be copied from prior to checking. If the value is blank, and this is either a regular file, directory, or a named pipe, a new empty version of this file is created if it does not already exist. For device files, a new special file is created for the same type device.

If a stanza in the /etc/security/sysck.cfg file does not specify an attribute, the corresponding check is not performed.

The tcbck command provides a way to define and maintain a secure software configuration. The tcbck command also ensures that all files maintained by its database are installed correctly and have not been modified.

tcbck Checking Programs

An important aspect of the tcbck program is the program attribute, located in the /etc/security/sysck.cfg file. The program attribute lists an associated program that can check additional status. This attribute allows for more thorough and flexible checking than other attributes provide.

You can use these checking programs to check the integrity and consistency of a file's contents and its relationship with other files. Checking programs need not be bound to a particular file.

For example, assume you wrote a program, /etc/profile, which verifies that each user's .profile file is writable only by that user. The program should have the following aspects:

You can add your program, /etc/profile, to the system security checker by entering the following:

tcbck -a /etc/profile 
"program=/etc/profile" class=profiles \ owner group mode

This command creates the following entry in the database:

class = profiles
owner = root
group = system
mode = TCB,rwxr-x---
program = "/etc/profile"

The following tcbck command verifies the installation of the /etc/profile program and runs the program:

tcbck -t profiles

There are several requirements for tcbck checking programs:

TCB Checking Programs

The operating system supplies the following TCB checking programs:

pwdck Checks the /etc/passwd and /etc/security/passwd files for internal and mutual consistency.
grpck Checks the /etc/group and /etc/security/group files for internal and mutual consistency.
usrck Verifies the accuracy of the user definitions in the user database files by checking the definitions for all the users or for specific users.

Secure System Installation and Update

Installing or updating a program consists of importing files into the system, usually creating new directories for the program, and occasionally reconfiguring the system itself. From a security standpoint, the program may need to add user accounts, define new audit events, and assign privileges to one of the program files.

In the simplest mode, a program installation consists of installing a new subdirectory tree (from /usr/lpp) and possibly adding new symbolic links in the /usr/bin directory. However, there are two problems:

To provide for secure program installation and update, two strategies are employed. First, privilege and access rights are delineated and limited during installation and update. This minimizes the potential for damage by untrustworthy installation packages. Second, the entire process is auditable. The auditing can be done by examining the system audit trail after installation or update of the program is complete, or auditing can be interactive. The watch command is provided for interactive use. The watch command can be used to execute a specified program and display the stream of audit records (if any) that are generated during the execution of that program.

This approach provides a great deal of flexibility in installation, while still providing a high degree of security. Even though the security is detection rather than prevention, this is still effective. Since the process is interactive, the installation of malicious programs can be halted quickly.

Guidelines for Ownership and Modes for Files

Normal User Commands

Normal user commands do not need a real owner or group since they can be executed by anyone and are not set user ID (SUID) or set group ID (SGID). If the command is expected to be run on the trusted path (for example, using the vi, grep, and cat commands), its TCB bit should be set. The following is an example of ownership and modes:

owner:  bin     r-x 
group:  bin     r-x 
others:         r-x
Administrative User Commands

Administrative user commands are executable only by root, members of an administrative group, and members who are specified in the extended access control list (ACL) entries. Since they usually perform privileged operations, some of these commands may need to be run with privilege (set user ID, or SUID). The following is an example of ownership and modes:

owner: root   r-x (possibly SUID)
group: system r-x (possibly SGID)
others: (possibly extended Access Control List entries)

For an example of a typical administrative user command scenario, consider network files containing critical network configuration information:

owner:  root             rw- 
group:  netgroup         rw-
others:                  ---

Use the changenet command to modify the information in the network file.

owner: root       r-x
group: netgroup   --s
(extended Access Control List entry)
permit r-x g:net
permit r-x u:john

In this example, group netgroup is an administrative privilege group with no members. Only processes running with group netgroup (or root user) can read or write the network files. Running the changenet command, which is the set group ID (SGID) netgroup, gives users the ability to change the network files. Only root users, members of group net , and user john can execute this command.

The Extended ACL Controls figure shows how the extended ACL is associated with the command instead of with the data files themselves.

The changenet command is the gateway to the network configuration files. The extended Access Control List on the changenet command is the guard that allows only certain users through.

This example assumes that there are more data files than programs that operate on them. If the reverse were true, it might make more sense to have ACLs on the data files.

Configuration Files

The following example shows the admin group as an administrative privilege group with no members. The exact name of the admin group depends on what type of configuration file the group applies to (for example, auditing, authentication, and mail).

owner:  root    rw- 
group:  admin   rw- 
others:         r-- 
mode:           TCB

In general, most configuration files should be readable by all users, with the exception of auditing and authentication data.

Device Special Files

In general, devices should not be readable or writable by normal users. Exceptions to this rule are terminal devices that should be writable so users can send messages to each other and floppy disks that should be both readable and writable so users can transfer files.

Trusted Communication Path

The operating system trusted communication path allows for secure communication between users and the Trusted Computing Base. Users start the trusted communication path by pressing the secure attention key (SAK). This allows only trusted processes to access the user's terminal. A trusted communication path is used whenever the user must enter data that must not be compromised (a password, for example). A trusted communication path can also be used by the person who administers the system to establish a secure environment for administration.

Note: If the Install Trusted Computing Base option was not selected during the initial installation, the trusted communications path will be disabled. The path can be properly enabled only by reinstalling the system.

The trusted communication path is based on:

After the SAK has been pressed, the init command starts either the getty command or the shell command that:

This assures that only the current getty or shell command has access to the terminal.

Trusted Command Interpreter

The getty command runs the shell command in response to a SAK only if the user was logged in to this terminal. This command establishes the terminal modes and runs the trusted shell (tsh command).

The tsh command provides a subset of the functions of the normal shell (Korn shell). The trusted shell executes only trusted programs (for example, programs tagged with the TCB bit). The built-in shell command allows the user to drop the trusted communication path and execute the user login shell.

Restricting Access to a Terminal

As mentioned previously, the getty and shell commands change the owner and mode of a terminal to prevent untrusted programs from accessing the terminal. The operating system provides a way to configure exclusive terminal access.

Using the Trusted Communication Path

A trusted communication path is established by pressing the SAK reserved key sequence (Ctrl-X, Ctrl-R).

A trusted communication path should be established under the following conditions:

Attention: Use caution when using SAK; it kills all processes that attempt to access the terminal and any links to it (for example, /dev/console can be linked to /dev/tty0).

Configuring the Secure Attention Key

Each terminal can be independently configured so that pressing SAK at that terminal creates a trusted communication path. This is specified by the sak_enabled attribute in /etc/security/login.cfg file. If the value of this attribute is true, recognition of the SAK is enabled.

If a port is to be used for communications, (for example, by the uucp command), the specific port used should have the following line in its stanza of the /etc/security/login.cfg file:

sak_enabled = false

This line or no entry disables the SAK for that terminal.

To enable SAK on a terminal, add the following line to the stanza for that terminal:

sak_enabled = true

[ Previous | Next | Contents | Glossary | Home | Search ]