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.
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.
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.
The tcbck command is normally used to:
The tcbck command can be used in three ways:
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.
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.
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 groups
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.
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
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
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:
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.
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:
/etc/profile: 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:
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. |
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.
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 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)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-xIn 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.
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.
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.
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.
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.
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.
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:
After you press the SAK:
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).
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
