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 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 includes 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.
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 the contents of a file 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 .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 might 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, two problems exist:
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. It can be used to run a specified program and display the stream of audit records (if any) that are generated during the running 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. Because 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 run by anyone and are not set user ID (SUID) or set group ID (SGID). Set the TCB bit if the command is expected to be run on the trusted path (for example, using the vi, grep, and cat commands). The following is an example of ownership and modes:
owner: bin r-x group: bin r-x others: r-x
Administrative user commands are run only by the root user, members of an administrative group, and members who are specified in the extended access control list (ACL) entries. Because they usually perform privileged operations, some of these commands might 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
others:(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 following figure shows how the extended ACL is associated with the command instead of with the data files themselves.
Figure 3-1. Extended ACL Controls. . This illustration shows users 1-6 grouped with the extended ACLs group net permit r-x. Another user, John, is designated with the extended ACLs user john permit r-x. Through the changenet command, these users are provided access to network data files depending on their extended ACLs.
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 are 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 are writable so users can send messages to each other, and floppy disks that are 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 communication path is disabled. The path can be 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 ensures 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 runs 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 run the user login shell.