C2 Security: Is Big Brother Watching?
Chris Hare As both the number and uses of computers have increased, so, too has the need for reliable security standards. Accordingly, the United States Department of Defense developed a collection of security standards and assembled them into the Trusted Computing Standards Evaluation Criteria, more commonly known as the Orange Book. C2, which is only one of several security levels, is by no means the highest, but it is the level adhered to by the majority of business-oriented UNIX vendors. In this article, I discuss a number of concepts and ideas that are applicable to systems other than SCO, as well as some SCO-specific implementation issues. I will not explore the sysadmsh in great detail, as it is a relatively easy tool to use, but I do discuss it when I address the topic of auditing. C2 security addresses total system security, including the physical machine, the software, backups, and the information stored on the physical media. If you follow the C2 guidelines, the end result is what is called a "trusted" system. But this system is only as "trusted" or "secure" as the physical machine and media. At the physical level, care should be taken to restrict the users who can access the system console, which is where the disk drives and keyboard are. By restricting access to the console, you limit the number of users who could alter the boot process with a different bootable disk. In addition, you must protect the software distributions: what good is it to lock access to the machine if the UNIX disks are right beside the system? Anyone could boot the system from those floppy disks, override your software protections, and access your data. The same is also true for backup media -- if the backup media is freely accessible, then anyone can access your data by reading your backup tapes. So, apart from the topics I cover here, remember that there is more to C2 than just the security of the operating system. The remainder of this article discusses:
Trusted vs. Secure Because no computer yet developed is completely free from risk, computer systems are not referred to as "secure," but rather as "trusted." A trusted system is defined as one that has a higher degree of control over the users on the system and the corresponding data. A trusted system prevents, or at least identifies, unauthorized access to the system. C2 Basics A collection of concepts and ideas -- some of them more logical than physcial -- form a large part of the definition of a trusted system. This section provides an overview of those concepts and ideas, then more detailed discussions follow. The heart of the trusted system is the "trusted computing base," or TCB. The base includes a collection of databases that store information on users, devices, and files, to detect unauthorized access. A wide variety of programs also form part of the computing base, which is the operating system's enforcement mechanism. A "subject" in a C2 environment is an entity such as a process, which is a program running on the UNIX system. "Objects" are such items as devices, files, and interprocess communication objects, like semaphores and shared data. The primary issue addressed by C2 security is accountability. An action is accountable only if it can be traced back to a single person. If there is any possibility that more than one person could have taken the action, then there is no accountability. Most UNIX systems lack accountability because the actions taken cannot be traced to a single user. Take the account "root," for example. Most sites use it for administering their systems because it is the only account which can do it all. It is not uncommon for several people in an organization to know the root password, so that all can perform the routine system administration tasks. This practice is one of the security holes in traditional UNIX. The question can be asked "Who removed that file?" and all can claim innocence, knowing that there is no way to trace their actions. In a trusted system, however, each real user is associated with a real account, and specific privileges and authority are granted to each user. This will be discussed in more detail later. The Discretionary Access Control (DAC) mechanism determines if a given user has the access rights to a given "object." On most UNIX systems, this object protection is implemented through the standard UNIX permissions mechanisms, consisting of permission bits for the owner of the file, the group owner, and all other users, as illustrated in Figure 1. The DAC mechanism allows specific users to modify the Set User ID (SUID) and Set Group ID (SGID) bits and make ownership changes, and it removes the extended permissions whenever a file is copied. You may think that this is all there is regarding permissions, but in fact there is more. Authorizations are used to grant a given user access to a particular action. C2 security provides for two types of authorizations -- kernel and subsystem. Kernel authorizations are associated with processes and allow a process to perform certain actions depending upon its authorization level. Subsystem authorizations are associated with individual users and allow a user to perform certain functions in the system. For example, manipulation of the Line Printer (lp) subsystem requires that the user have the lp authorization. The lp authorization allows the user to access commands such as lpadmin to perform printer maintenance. Logging in to a C2 trusted system involves a few additional checks besides the usual password checking performed for a typical UNIX system (see "How UNIX Password Controls Work," Sys Admin 1:1, May/June 1992). The trusted system searches the password file as usual and validates that the password provided is in fact the correct password. A record is kept for each user account defining when the user last successfully and unsuccessfully logged in to the system. This is an easy way for users to see if their account is being violated, provided they haven't disabled this reporting mechanism. In addition, C2 imposes further controls enforced on password generation, making passwords unusable that would be accepted on non-C2 trusted systems. The major component in providing accountability to a C2 is the Audit Mechanism. Auditing is not just an extension of the traditional UNIX process accounting system. With process accounting, the system keeps limited records regarding what processes executed on the system and who executed them. It keeps no records regarding what objects (files or devices) were accessed. Auditing corrects this weakness of process accounting. A wide variety of system events can be monitored, providing an audit trail or record of all actions taken by every user on the system. Using this audit trail, which according to the Orange Book must be kept until that iteration of the Operating System is destroyed, the System Administrator, Audit Administrator, or Security Office could review it to determine when a specific action occurred, what happened, and who was involved. Finally, there are the Protected Subsystems. These subsystems make use of the SUID and SGID bits to restrict access to only those users who are members of that group. Even though it may appear that a particular command is SGID and belongs to a particular group, that command is not necesarrily part of the subsystem. At the same time, simply putting the user in the desired group is not enough -- there are other authorizations which typically must also be granted. The Trusted Computing Base Filesystem The files that make up the databases for the TCB are scattered in several different directory hierarchies. SCO is adamant about not editing many of these files, because corrupting one of them may make it impossible for you to log in to correct it. If you find it necessary to edit one or more of these files, make sure that you have a full backup available and proceed with caution. The majority of the files and programs required to maintain the TCB are in the /tcb directory structure, shown in Figure 2. The user information is only partially stored in the /etc/passwd file. As Figure 3 shows, the /etc/passwd file contains an asterisk in the field where the password would normally be. Additional user information is stored in the /tcb directory structure, under /tcb/files/auth/[a-z]/username, where the [a-z] refers to the corresponding directory with the same first letter as the user's name. For example, my login name is chare, so the information on my user account will be found in the directory, /tcb/files/auth/c. The contents of this file are shown in Figure 4, along with an explanation of each entry. Information for the Terminal Control Database is also stored under /etc/auth. This is where unsuccessful logins on each terminal device are logged. When the maximum is reached, the terminal device is locked or disabled until the system administrator clears the lock. The locking mechanism makes it easier for the system administrator to see if there is a potential problem with someone trying to gain access to the system. The /etc/auth directories are illustrated in Figure 5, with the primary Terminal Control file illustrated and explained in Figure 6. Administrative Roles Just as in an organization an individual typically has a primary role and several secondary roles, so too does a user on a computer system. The different roles can be used to grant users specific access to the parts of the system for which they will have administrative responsibility. Table 1 identifies the administrative roles recognized by C2: note that the apparent correlation between the administrative roles and the protected subsystems is somewhat misleading. In fact, the issue is more complicated than this suggests. The primary benefit to assigning roles is to distribute the work, that is, to allow people to perform certtain tasks without needing to use the root account, thereby keeping the accountability intact. Administrative roles are logical ones. This means that nowhere in the SCO system is a specific person identified as, say, the audit administrator. Rather, this association is performed by granting the associated privileges using the System Administration Shell, or sysadmsh. Protected subsystems often require that a user also have some kernel authorizations in order perform various operations. Table 2 lists the kernel authorizations and provides explanations of how they work. Table 3 lists the different protected subsystems and their related kernel authorizations. Password Control Password control is a critical aspect of security on any system, and trusted systems focus intense attention on this area. The enhanced password control mechanisms are modeled after the United States Department of Defense Password Management Guideline, the Green Book. It enforces much more stringent controls for users who can pick their own passwords. The authorizations administrator can specify which users can choose their own passwords and which must have passwords generated for them by the system. Once the system chooses the password, it can be subjected to simple or extensive checking. Simple checking looks for circular shifts of the login name. Extensive mode checks a large system dictionary of words that cannot be used as passwords. Another feature of the trusted environment: user accounts can be locked. For example, if the user attempts to login but consistently types the wrong password, then that user's account will be locked by the system. This is the system's attempt to detect and control a possible breakin. The system administrator may apply an administrative lock. In both cases, the user will get a message upon attempting to login stating that the account is locked and that the user should see the system administrator. Reports can be generated about user login activity on the system, as shown in Figure 7. The report lists each user in the password file, and reports on the last sucessful and unsuccessful logins for that account. It also notes the number of failed logins and if the account is locked. If the locked field is set to "Y," then the user is unable to login until the system administrator unlocks the account. Terminal Management Before moving on to Auditing, I want to discuss terminal control. As I mentioned earlier, the TCB records system activity on terminals. This is especially important as the terminal is the gateway to the system. A trusted system allows a predefined number of unsuccessful login attempts before disabling or locking (depending on the security level enabled) the terminal device. The default number for C2 systems is 5. This means that after five unsuccessful login attempts, the terminal is locked and all later login attempts will be advised that the terminal is disabled. The report shown in Figure 8, which is created from the system administration shell, lists the current login states of the various terminals on the system. This is for all terminals, including the network terminal ports. This report lists the last good and bad logins, indicating who and when, the last logout on that port, and the number of failed attempts to login. Notice that tty04 has had six unsuccessful login attempts. System Auditing The primary reason for implementing C2 security is to be able to find out what everyone is doing with the available computing resources. For sites concerned about confidential information, C2 provides a means of tracking access. Through auditing it is possible to see who and what processes accessed any file in the system. The audit system consists of several components:
The Kernel Audit Mechanism The kernel audit mechanism tracks user activity through the system calls that each process executes to perform work. For example, the open(S) system call is classified as a "make object available" event. It makes the object, and the data, available to the program for reading and, if authorized, for update. However, if a user who doesn't have the necessary permission attempts to open the file for write or update, a Discretionary Access Control (DAC) denial is recorded for that file. System calls can be selectively enforced. A few system calls, such as getpid(S), which returns the PID of a process, are not considered a threat to security and so are not audited. The Audit Device Driver The audit device driver is responsible for:
The audit device interacts like any other device, except that only those processes with configuaudit or writeaudit authorization can successfully open the device. In this fashion only those processes that have been deemed trusted can open and interact with the audit device. There is no need to worry about lost records because of many processes writing to it. The driver takes care of merging all of the records into the audit trail. However, only the audit daemon can read from the device. The audit driver maintains the audit trail as a sequence of audit collection files. Each time you restart auditing, a new session is started. An audit data file grows quickly: on one test machine, after only a couple of hours, the file contained over 38,000 audit records. Interaction with this file is done through the system administration shell. The Audit Compaction Daemon This daemon is a trusted program which runs in the background whenever auditing is running. The purpose of this daemon is to read records from the audit device and to provide a compaction and logging mechanism. In this case compaction means actually compacting the information into a size which is suitable for storage. It is not uncommon on a single user system to generate over 200Kb of audit data per hour. The compaction daemon can reduce the required space by 60 percent. This greatly saves on the amount of disk space required to store the audit records. The Audit Interface The audit or system administrator interacts with the audit system through the system administration shell, sysadmsh. This allows for configuring the audit system parameters, maintaining the subsystem authorizations, and reviewing the audit reports. The Data Reduction and Analysis Facility This facility examines audit trails from previous or current sessions to analyze and report on the activity within the session. What Is Being Audited? The events available for audit, on both a system-wide basis and a per-user basis, are listed in Table 4. Please refer to your system documentation for an explanation of each event. For each event, system administrators can selectively control whether the event is audited or not by changing the System Audit Event Mask. This mask is global to the entire system. If you have a need to edit or change the audited event list, it can be done during auditing. For each user, the event mask can also be adjusted. While the global event mask can only be on or off for each event, the user audit mask can be set to
Guidelines for Auditing To be effective at auditing, you must set some guidelines for your installation that define what will be audited and when. The audit system is extremely flexible and can be customized to allow for tracking the desired events. If you use preselection to determine which user IDs or events you want to audit, you will consume less disk space (unless, of course, you decide to audit everything). However, there is a drawback: if the event you want to look for hadn't already been specified for audit, you won't find instances that occurred before you added it. For this reason, it is typically desirable to select all events for auditing, and to be selective when generating the reports. Reports The SCO C2 report generator can generate several predefined reports, including:
but you can create other reports to suit your own needs. Figure 9 shows the information available at the beginning of every audit system report:
Figure 10 shows three sample records from the Discretionary Access Control Denials report. These entries show a successful open, file permission change, and a file ownership change. Aside from the reports identified above, which ship as part of the C2 configuration, it is also possible through the reports interface in the system administration shell to define your own parameters for a report, and then generate it. Caveats There are a couple of caveats to running auditing on your system -- it does consume disk space, at approximately 200Kb per hour on a single user system or 8 x 200K = 1.6 Megabytes per hour on an eight-user system! You must have the capacity to store these records. Also, to be truly C2-compliant, you must keep these records on some accessible storage medium until the system is reinstalled. Finally, there is a performance hit, but that is dependent on the amount of CPU power you have to begin with. Conclusions C2 isn't for everyone, and because some people may feel that their every action is being watched (as it is), there may be some resistance to running C2 where it isn't formally required. I don't know of any legal actions that have been taken as a result of a C2 audit trail, but it wouldn't surprise me to hear of one. I'd be interested in hearing from readers who are actually running C2 UNIX. I'd like to know why you are running C2 and what your experiences have been with it. I have by no means covered all there is to know about C2; rather, I have only revealed the tip of the iceberg. For more information you should consult the chapters on C2 security in your related system documentation.
About the Author
Chris Hare is Ottawa Technical Services Manager for Choreo Systems, Inc. He has worked in the UNIX environment since 1986 and in 1988 became one of the first SCO authorized instructors in Canada. He teaches UNIX introductory, system administration, and programming classes. His current focus is on networking, Perl, and X. Chris can be reached at chare@choreo.ca, or chare@unilabs.org, which is his home.
|