|
|
The following defines the basic concepts of a trusted system. As administrator, you must understand these concepts and know where security-relevant information is kept to run the system properly. This section only introduces these topics; later sections in this chapter provide further details and describe maintenance procedures.
A collection of software called the ``trusted computing base'' (TCB) maintains the parts of the system that are related to security. The TCB consists of the UNIX system kernel (the heart of the operating system) and the trusted utilities that reference and maintain relevant security data. The TCB implements the security policy of the system. The security policy is a set of rules that oversee and guard interactions between ``subjects'' (such as processes, which are programs running on the system) and ``objects'' (such as files, devices, and interprocess communication objects). At the C2 level, this consists of ``discretionary access control'' (DAC), discussed later in this section, and object reuse (which dictates that information in a storage object must be cleared before allocation). Much of the software that you interact with is part of the system's TCB. SCOadmin provides a menu-driven interface to help you maintain the TCB.
On a trusted system, all actions can be traced to a responsible person. Most UNIX systems lack good accountability because some actions cannot be traced to a person. For example, pseudo-user accounts, such as lp or cron, run anonymously; their actions can be discovered only by changes to system information. As described later, a trusted UNIX system improves accountability by associating each account with a real user, auditing every action, and associating each action with a specific user on the system.
On a typical UNIX system, each process has a real and effective user ID as well as a real and effective group ID. A process with the effective user ID set to root can set these identifiers to any user. The C2 level of trust requires that the TCB be able to identify each user uniquely and thus enforce individual accountability. The concept of user identity is expanded on trusted UNIX systems to add a separate identifier called the ``login user identifier'' (LUID). The LUID is an indelible stamp on every process associated with a user. The LUID identifies the user who is responsible for the process's session. Once stamped, the process's LUID cannot be changed by anyone. Child processes inherit the LUID of their parent.
Discretionary access control (DAC) determines whether a user has access to desired data. That information is within an ``object'' (file, device, and so on) that the user's process is trying to use. On most UNIX systems, object protection is enforced through the relationship between the user and the group of a process and the owner, group and other mode bits of the object. The protection attributes of these objects are at the discretion of the object's owner, who can change the protection bits on a file and even give the file away (change ownership). Your SCO OpenServer system extends the standard discretionary access control rules used by the UNIX file permissions by restricting the:
As required by the C2 level of trust, SCO OpenServer systems always clears the information in a storage object (memory, whether in RAM or secondary storage) before re-allocating the resource. This prevents users from gaining access to residual data belonging to other users.
Authorizations and privileges are user attributes required to
perform certain actions. Most UNIX systems
make all access decisions based on the simple file permissions
or on whether the process making the access is owned by root.
The root account can perform system actions that no other
process can. System privileges are associated with processes
and allow a process to perform certain actions
if the process has the requisite privilege.
Subsystem authorizations are associated with users.
They allow the user to perform a special action using
a subsystem's commands (trusted utilities and programs). A ``subsystem''
is a related collection of files, devices, and commands that serve a
particular function. For example, the lp subsystem consists
of the print spooler files, the printer devices, and commands such as
lpadmin(ADM)
that help maintain the subsystem.
In this way,
authorizations allow you to assign ``administrative roles'':
users entrusted with administering specific subsystems (such as the
print service).
Privileges are stored in an ``privilege set'' associated with every process. Thi is a list of privileges which allow a type of action if the privilege is present, and do not allow the action if the privilege is absent. Privileges are either set by the system defaults or defined for a specific user.
When a user logs into a non-trusted UNIX system, limited identification and authentication (I&A) takes place. The system searches the password database (/etc/passwd) for the user name. If the user name is found, the system authenticates the user by comparing the password entered to the encrypted version of the password in the user's password database entry. Some rules concerning the characteristics of the password and the ability to change it may be enforced, but these rules have been shown to be insufficient to guard against penetration.
SCO OpenServer systems extend the standard UNIX system I&A mechanisms. There are more rules enforcing the types of passwords that can be used. There are new procedures for generating and changing passwords. The location and protection of certain parts of the password database differs from that of other UNIX systems. The administrator also has greater control over the login process. A separate role, called authentication (or accounts) administrator (with subsystem authorization auth), is charged with account administration.
Most UNIX systems keep a limited record of system actions with their
accounting subsystem. The accounting subsystem writes a single accounting
record upon completion of each user process. SCO OpenServer systems provide an
extensive series of records that form a ``trail''
of actions. In this trail is a record of every access between subject
and object (successful and unsuccessful)
and every change of subject, object, and system characteristics.
The audit subsystem is controlled by a separate role called
audit administrator (with subsystem authorization audit).
The audit administrator decides how much information is recorded, and how
reliably it is recorded and maintains the information once it is
collected. The audit subsystem provides the audit administrator
with an extensive history of system actions. This helps
the administrator to identify what happened to the system,
when it occurred, and who was involved.
UNIX systems provide the SUID and SGID mechanisms that allow programs to set the user of group ID of a process with the setuid(S) and setgid(S) system calls and permission bits described in chown(C). With these you can construct programs that maintain protected information. This information can only be accessed or modified by the operations implemented in the programs. The TCB defines several protected subsystems. Each of these subsystems consists of a collection of private information (files and/or databases), any related devices, and the utilities and commands used to maintain that information. The protected subsystems use the SUID/SGID mechanisms to protect their private files, databases, and devices from unrestricted access. The trusted system extends the notion of a protected subsystem in several ways: