Can You C2?

M.L.A. Lammerse

Does your computer system store or process sensitive information? In one way or another, it probably does -- a risk analysis of your corporate firewall, executive reports, financial data, the list could go on. These are just a few examples of highly sensitive data that you wouldn't want to fall into the wrong hands. While a lot of third-party products exist to enhance your system's security at the application level, there's really no better way to start than at the bottom of it all: the operating system.

In this article, we'll look at how military-grade security, in particular the C2-level, compares to standard UNIX security and whether the increased security outweighs the administrative burden that comes with a secure operating system. Although the security levels defined by the so-called Orange Book (described below) are about to be replaced with a new security assessment system at the federal level (C2 systems, for example, are no longer evaluated), Orange Book levels remain those which most systems administrators are at least minimally familiar with.

The United States Department of Defense (DoD) has very stringent security requirements for its computer systems. The operating systems that are being used within the DoD must be secure in order to protect highly classified information. Although the average company does not handle military secrets, they too appear to require the security features used by the DoD.

What defines a secure operating system? How would you compare the security offered by one system to the other? What guarantees exist that the security features are correctly implemented? To provide a metric for comparing computer system security, the DoD developed standard 5200.28-STD, The Trusted Computer Systems Evaluation Criteria (TCSEC).

The TCSEC is a set of criteria used to grade or rate the security features offered by a computer systems product in commercial product evaluations. (Although the TCSEC has been applied to other products such as firewalls and routers, the scope of this article is limited to operating systems.) It is also referred to as the “Orange Book” because of its orange cover. The Orange Book is part of a larger collection of standards, each with a different colored cover; together, they comprise the so-called Rainbow Series.

The criteria are divided into four divisions: D, C, B and A. They are ordered in a hierarchical manner, with the highest division (A) being reserved for systems providing the most comprehensive security. Each division represents a major improvement in the overall confidence one can place in the system for the protection of sensitive information.

Within each division, a number of subdivisions known as classes exist. They are also ordered in a hierarchical manner. The seven classes defined in the TCSEC, in ascending order of security-level are: D,C1,C2,B1,B2,B3 and A1 (see sidebar). Each division includes the security features and assurance level of the lower division (e.g., A B1 level operating system would include all of the requirements for the C2 level).

Product evaluations are performed at a vendor's request by the National Computer Security Center (NCSC), a division of the National Security Agency (NSA). The TCSEC, along with a large number of related standards and guidelines for interpreting them, are freely available from the NCSC's Web site:

http://www.radium.ncsc.mil/tpep

The classes defined in the TCSEC are based upon a number of security requirements. The difference in level of compliance are the requirements that would, for example, separate a C2-level system from a B1-level system. To understand the class's requirements, a brief overview is presented here:

Security policy -- The system must be capable of enforcing a well-defined security policy. The security policy is a set of rules that regulates how an operating system manages, protects, and distributes access to sensitive information. A security policy might state, for example, that interactive system logins are only allowed on specific terminals.

Marking -- To control access to information stored in a computer, the system must be capable of marking every object with a label that reliably identifies its sensitivity level (e.g., classification).

Systems supporting these labels are B1-level secure and are described in the Compartmented Mode Workstation (CMW) specification 3. (Defense Intelligence Agency, Compartmented Mode Workstation Evaluation Criteria, report DDS-2600-6243-91.) In short, the information protected by the operating system is logically divided into compartments. Every piece of information, whether it is a file or a network packet, is associated with a sensitivity label. The sensitivity label could be any of the following:

• unclassified

• sensitive

• confidential

• secret

• top secret

A compartment is a subdivision of one type of classification. An example of two compartments would be: secret finance and secret accounting (the compartments of finance and accounting). Access to the classified information is granted when the user's clearance dominates the sensitivity label of information. An employee with a confidential clearance would be unable to access information in the secret finance compartment in contrast to the finance department's manager, who possesses a secret clearance for both compartments.

Identification -- The operating system must be able to identify individual users. Traditionally, UNIX systems have employed the standard username/password mechanism to identify users. After login, a user's identity is associated with a numerical userid. This userid is then used by the operating system to determine, for example, if that particular user has access to a file.

Accountability -- It must be possible to record auditing information for selected events on a per-user basis. An administrator must be able to trace back a security violation to the responsible user. Also, audit data must be protected from modification and unauthorized destruction.

Assurance -- The system must contain implementations of clearly documented security features, either hardware or software based, that can be independently evaluated to ensure that the system enforces the previously mentioned requirements.

Continuous Protection -- The implemented security mechanism must be continuously protected against tampering and unauthorized changes. No computer system can be considered truly secure if the basic hardware and software mechanisms that enforce the security policy are also subject to unauthorized modification or subversion.

These fundamental requirements are the basis for TCSEC's evaluation classes. You'll find a summary of the TCSEC classes and their conceptual differences in the sidebar.

Practical C2 Security

How do the TCSEC requirements translate into real-world security mechanisms? Consider HP-UX for example. Although it has not been officially certified by the NSA, it is one of the few mainstream UNIX flavors that offers C2-level functionality.

After an out-of-the-box installation, HP-UX runs in untrusted mode, which only provides standard UNIX security. HP-UX's C2 security features are activated by running the system in C2-level trusted mode. You can switch between the two modes by running HP-UX's administrative tool System Administration Manager (SAM) and performing the following steps:

1. Select Auditing and Security from SAM's main menu.

2. Select Audited Events -- The following message is displayed as soon as you click on any of the auditing options for the first time:

You need to convert to a Trusted System before proceeding.

Converting to Trusted System does the following:

1. Creates a protected database on the system for storing security information

2. Moves user passwords in "/etc/password" to this database

3. Replaces all password fields in "/etc/password" with "*"

Do you want to convert to a Trusted System now?"

3. Answer yes. The system will then display:

Converting to a trusted system...

Successfully converted to a trusted system.

Press OK to continue.

4. Select OK.

Discretionary Access Control

Discretionary Access Control (DAC) allows owners of objects containing data, such as files or devices, to allow or deny access at their own discretion. One user might create a document and give read-write access to user A, but provide user B with only read access.

At first glance, this does not seem different from standard UNIX security, where you can assign read, write, and execute rights to users that fall into the categories “owner”, “group”, or “other”. However, the TCSEC states that discretionary access controls of a C2 system must be capable of including or excluding access to the granularity of a single user. This means that one could own a particular file and provide five different users with five different types of access -- something that's beyond the capability of a standard UNIX system.

There is one caveat -- the filesystem has to support Access Control Lists (ACLs). ACLs are parts of the filesystem in which information is stored about specific user access to an object. For the HP-UX operating system, that would be the Journaled File System (JFS). If you do not have a filesystem installed that's capable of storing ACLs, you will not be able to assign detailed access rights.

On files that are located on a journaled filesystem, you could use the lsacl and chacl commands to inspect and set access rights:

# lsacl /etc/passwd
# (root.%,rw-)(sys.%,---) /etc/passwd

Object Reuse

The Trusted Computing Base (TCB) must ensure that dynamically allocated and released memory is cleared upon reallocation to prevent information produced by one user from becoming available to another. Why is that important? Suppose user A generates a set of cryptographic keys to digitally sign an important document. When the application that was used to sign the document is terminated, it should not be possible for user B to request a memoryblock that contains those keys. This would obviously be a severe security hole. Therefore C2-level secure systems clear memoryblocks before they are released back to the heap.

Identification and Authentication

Users must be uniquely and reliably identified to be accountable for any actions they perform through in operating system. The TCB therefore is responsible for verifying a user's identity and protecting its credentials.

On a standard UNIX system, users are authenticated by a username/password combination. This scheme is generally considered weak, especially when no guidelines exist for the use of strong (i.e., hard to guess) passwords. HP-UX includes more stringent password authentication through a password management mechanism (as specified in DoD Password Management Guideline, standard CSC-STD-002-85). This standard poses password format restrictions, making them more resistant to a brute-force attack.

If you're looking for stronger methods of authentication, modern versions of UNIX support Sun Microsystems' Pluggable Authentication Modules (PAM) technology. PAM allows for the separation of an application (e.g., the login process) and its authentication mechanism. The authentication part becomes modularly replaceable. Using PAM, integrating token-based authentication into your system becomes trivial.

PAM is a standard part of modern versions of (among others) Solaris, HP-UX, and Linux. You can find more information on PAM technology on Sun's Web site:

http://www.sun.com/software/solaris/pam

Auditing

In a trusted system, all users are held accountable for their actions. Any security-relevant action must be traceable to a particular responsible user. HP-UX creates an audit trail of security-relevant events, such as any attempt to bypass the protection mechanisms, modification of access rights, login failures, mounting and unmounting of filesystems, deletion of files, etc. Maintaining and examining audit information consists of the following tasks:

• Determine how much information to collect in the audit trail

• Configure the audit subsystem collect the desired information

• Analyze the audit trail to monitor system activities

HP-UX's auditing subsystem monitors the kernel's system calls on a per-user basis. Some of the calls are grouped into events, such as “admin”, and “modaccess”, as shown in Table 1.

The amount of information generated can be quite substantial. The exact amount depends entirely upon the number of users and events being audited. In case of a security incident, it is better to have more information than you need, rather than too little. To keep an eye on the size of the logfiles, HP-UX runs the audomon-daemon, which will issue warnings when their sizes reach certain limits. If it is no longer possible to write audit data, execution of the audited systemcalls is suspended for all but the root user to prevent loss of vital information.

The audit files themselves contain a lot of highly detailed information, and it's a pain to have to sift through the data to find what you're looking for. SAM supports detailed filtering options to select only the events you're interested in, but even then it's a lot of work. A typical line in the audit-trail looks like:

TIME                PID    E   EVENT  PPID   AID    RUID  RGID
990511 17:15:09     2955   S   45     2954   0      0     3
[ Event=utssys; User=root; Real Grp=Sys Eff Grp=Sys;]
    RETURN_VALUE 1=0;
    PARAM #1 (addr of char) = 2138974192
    PARAM #2 (int) = 0
    PARAM #3 (int) = 0

If this trail seems confusing to you, don't think you're the only one. Information like this is hard to analyze and really just adds work for your systems security officer (if you have one). Systems administrators cannot be bothered with this kind of cryptic information. They need a tool that will provide a high-level abstraction of security-related events. The lack of available software doesn't make things easier for the security conscious.

Secure OS Availability

Looking for a secure operating system? Systems that have been successfully evaluated by the NSA are given a place in the Evaluated Products List:

http://www.radium.ncsc.mil/tpep/epl

Although this list was not up to date at press time, notably missing were the current versions of major UNIX operating systems. Based on initial commercial customer reaction, and various other factors, UNIX vendors have not implemented high levels of security as the default configuration within their operating systems. Instead, most offer security extensions to their base OS, allowing you to choose the appropriate level of security for your systems. Vendors that want to play in the federal market also have comprehensive evaluation programs in place.

In most cases, the operating systems being used on your systems were chosen based on application requirements or other factors. OS security is seldom the primary selection criterion outside the Federal market. Thus, the first choice available to you is to implement whatever security extensions are available from the OS vendors represented in your mix of machines. Essentially, you replace the base OS with the secure version, on a system-by-system basis.

Replacing all of the operating systems running within the company with secure versions may not be a viable solution for everyone. There are alternatives, however, for those looking to enhance the security level of their operating systems, such as using Memco's Security for Open Systems (SeOS). (Memco was recently acquired by Platinum. Details can be found at: http://www.platinum.com.)

SeOS is basically a kernel module, which intercepts systemcalls and determines whether the user generating the systemcall has sufficient privileges to execute it. The beauty of this is that your operating system does not have to provide native support for access control lists; they are added by SeOS. SeOS also tackles the all-powerful root problem. With SeOS, it is no longer necessary to give the root user full control over the system and the information contained within. More details can be found at the vendor's Web site, which also lists an extensive whitepaper:

http://www.memco.com/products/products_f/download/seos_unix.html

TCSEC C2-level security requires extensive auditing and access control. While standard UNIX systems are limited in that respect, third-party products such as SeOS are available to get your security up to par. The administration of a secure operating system, especially when it comes to auditing, still is cumbersome and will require extra effort on your systems administrator's part. Tools for analyzing auditing data are not (yet) widely available, making it a costly affair to keep a security conscious eye on things. The question is: Are you willing to invest now, or pay the price later?

About the Author

Ing. Lammerse is currently working as a computer security consultant for ITsec Nederland BV in the Netherlands. He may be contacted at m.lammerse@itsec.nl.