|
|
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.
The SCO OpenServer security policy prescribes a relationship between access rules and access attributes. The access attributes allow the system to define several distinct levels of authorization, and the access rules provide the mechanism for the system to prevent unauthorized access to sensitive information.
Access to a file is determined by the file's absolute pathname. The kernel determines whether or not to allow a process the kind of file access requested (read, write, execute/search) based on
For example, if the file
/usr/src/cmd/mv.c
is readable by a user,
but the directory
/usr/src/cmd
(or any other directory in the path)
is not searchable by the user
(that is, the user does not have
search permission on
/usr/src/cmd),
then
mv.c
cannot be read.
The system enforces access control by means of the Discretionary Access Control (DAC) mechanism.
Users on a computer system typically share commands, programs, library routines, and files. For example, all users need to share the user-level commands in the operating system, such as ls, cp, ed, and so on. Also, users in the same group or in related groups often may want to share some of the same data or text files. Object sharing introduces some potential security violations. To maintain security, the security policy requires that the system oversee object sharing in a known and controlled manner.
DAC provides for the controlled sharing of objects among subjects. DAC is part of the ``who can access what'' mechanism. With DAC, the owner of an object can choose to grant access permissions to other users; that is, the segregation of information and the prevention of unauthorized access to information is set according to the discretion of the owner of the information.
Two complementary DAC mechanisms are available:
File permission modes are retained from previous releases of SCO OpenServer for compatibility. Administrators already familiar with SCO OpenServer file permissions will find that this mechanism still works as expected. For more information on file permission modes, see ``Protecting the data on your system''.
ACLs are designed to satisfy B2-level US government security requirements and to be compatible with file permission modes.
A given combination of permission mode bits on a file is directly translated into a basic ACL for that file; it provides identical protection. The ACL on a file can be displayed by invoking the getacl command. The owner of the file can add more users and groups to the basic ACL by invoking the setacl command. Refer to getacl(C) and setacl(C) for more information concerning these commands.
The ACL concept supports finer control than file permissions alone by providing the ability for the owner of an object to grant or deny access by other users to the granularity of a single user. All DAC information may be changed in one atomic operation with the setacl command, avoiding the possibility of an intermediate insecure state.
ACLs also allow specification of access rights to members of groups as defined to the system in the administrative file /etc/group. ACLs can be arbitrarily large; that is, the number of ACL entries is not limited by the system. The system administrator can set the maximum number of entries per ACL by setting a tunable parameter. (Naturally, as ACLs get larger, processing gets slower, which induces a practical limit on the number of ACL entries.)
ACLs are associated with each filesystem object on a Secure Filesystem (sfs) or Veritas Filesystem (vxfs) and IPC object. ACLs for filesystem objects are stored in the associated inode. ACLs for IPC objects are stored in an internal structure associated with the instantiation of the IPC object.
The commands that a user can invoke to manipulate and read DAC permissions are:
The system calls that a program can invoke to manipulate and read DAC permissions are: The library function for reading and sorting ACL information is: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: