Search the Catalog
Computer Security Basics

Computer Security Basics

By Deborah Russell & G.T. Gangemi, Sr.
1st Edition July 1991
0-937175-71-4, Order Number: 714
464 pages, $29.95

Chapter 3
Computer System Security and Access Controls

Computer security covers a lot of territory: locking your computer room and your machine, protecting your login accounts with passwords, using file protection to keep your data from being destroyed, encrypting network communications lines, and using special shields to keep electromagnetic emanations from leaking out of your computer. But when people talk about computer security, they usually mean what in this chapter we call computer system security.

What Makes a System Secure?

In the most basic sense, computer system security ensures that your computer does what it's supposed to do–even if its users don't do what they're supposed to do. It protects the information stored in it from being lost, changed either maliciously or accidentally, or read or modified by those not authorized to access it.

How does computer system security provide protection? There are four primary methods:

  1. System Access Controls.
    Ensuring that unauthorized users don't get into the system, and by encouraging (and sometimes forcing) authorized users to be security-conscious–for example, by changing their passwords on a regular basis. The system also protects password data and keeps track of who's doing what in the system, especially if what they're doing is security-related (e.g., logging in, trying to open a file, using special privileges).

    The section "System Access: Logging Into Your System" introduces the basics of system access controls. Chapter 6, Inside the Orange Book, describes the Orange Book accountability requirements, which specify the system access controls defined for different levels of secure systems. In particular, see the section entitled "Accountability Requirements" in that chapter.

  2. Data Access Controls.
    Monitoring who can access what data, and for what purpose. Your system might support discretionary access controls; with these, you determine whether other people can read or change your data. Your system might also support mandatory access controls; with these, the system determines access rules based on the security levels of the people, the files, and the other objects in your system.

    "Data Access: Protecting Your Data" introduces the basics of data access controls. In Chapter 6, the section entitled "Security Policy Requirements" describes the Orange Book security policy requirements, which specify the data access controls defined for different levels of secure systems.

  3. System and Security Administration.
    Performing the offline procedures that make or break a secure system–by clearly delineating system administrator responsibilities, by training users appropriately, and by monitoring users to make sure that security policies are observed. This category also involves more global security management; for example, figuring out what security threats face your system and what it will cost to protect against them.

    Chapter 5, System Security Planning and Administration, introduces the basics of system security planning and administration. In Chapter 6, the section entitled "Assurance Requirements" describes the Orange Book system administration requirements defined for different levels of secure systems.

  4. System Design.
    Taking advantage of basic hardware and software security characteristics; for example, using a system architecture that's able to segment memory, thus isolating privileged processes from nonprivileged processes.

    Although a detailed discussion of secure system design is outside the province of this book, the section "System Architecture" in Chapter 6 describes briefly the major Orange Book design requirements for different levels of secure systems.

System Access: Logging Into Your System

The first way in which a system provides computer security is by controlling access to that system: Who's allowed to log in? How does the system decide whether a user is legitimate? How does the system keep track of who's doing what in the system?

What's really going on when you try to log into a system? It's a kind of challenge. You tell the system who you are, and the system proves that you are (or you aren't) who you claim to be. In security terms, this two-step process is called identification and authentication.

Identification and Authentication

Identification is the way you tell the system who you are. Authentication is the way you prove to the system that you are who you say you are. In just about any multi-user system, you must identify yourself, and the system must authenticate your identity, before you can use the system. There are three classic ways in which you can prove yourself:

  1. Something you know.
    The most familiar example is a password. The theory is that if you know the secret password for an account, you must be the owner of that account. There is a problem with this theory: You might give your password away or have it stolen from you. If you write it down, someone might read it. If you tell someone, that person might tell someone else. If you have a simple, easy-to-guess password, someone might guess it or systematically crack it.

  2. Something you have.
    Examples are keys, tokens, badges, and smart cards you must have to "unlock" your terminal or your account. The theory is that if you have the key or equivalent, you must be the owner of it. The problem with this theory is that you might lose the key, it might be stolen from you, or someone might borrow it and duplicate it. Electronic keys, badges, and smart cards are gaining acceptance as authentication devices and as access devices for buildings and computer rooms. With the proliferation of automatic teller machines (ATMs), people are becoming increasingly familiar with this type of authentication.

  3. Something you are.
    Examples are physiological or behavioral traits, such as your fingerprint, handprint, retina pattern, voice, signature, or keystroke pattern. Biometric systems compare your particular trait against the one stored for you and determine whether you are who you claim to be. Although biometric systems occasionally reject valid users and accept invalid ones, they are generally quite accurate. The problem with these authentication systems is that, on the whole, people aren't comfortable using them.
Passwords are still, far and away, the authentication tool of choice. Even when authentication devices like tokens and biometric devices are used, they're usually supplements to, not replacements for, conventional login IDs and passwords. Biometrics and key cards typically act only as a first line of defense against intruders, not as the only defense. (See Chapter 9, Physical Security and Biometrics, for a discussion of authentication devices.)

In most systems, you identify yourself to the system by entering some kind of unique login identifier, followed by a password. The identifier is typically a name, initials, a login number, or an account number assigned by the system administrator based on your own name and/or group. The password is typically a string of letters and/or numbers known only to you. Login identification sequences are much the same from system to system. For example, UNIX systems display the prompt:

and expect a first or last name (or any other handle you've been given) in response. Other systems may expect an identifier of a specific length–for example, a three-character ID (usually your initials) or an account number.

The typical password interaction is usually a relatively simple and user-friendly one. After you enter your login ID, the system prompts:

You type the password (which is ordinarily never echoed, or displayed, on the terminal screen), and the system authenticates your identity by verifying that the entered password is valid for your account. You'll be able to proceed only if the password you enter matches the password stored for you in the system.

Hints for Protecting Passwords

Both system administrators and users share responsibility for enforcing password security. Remember, password security is everyone's responsibility. In addition to damaging your own files, someone who uses your password to break into a system can also compromise all of the files in your system or network.

From the USENET: "A password should be like a toothbrush. Use it every day; change it regularly; and DON'T share it with friends."

Passwords are your main defense against intruders. To protect your system and your data, you must select good passwords, and you must protect them carefully.

Once you've been authenticated, the system uses your ID (and the security information associated with it) to determine what you're allowed to do in the system. The system uses this information to make access decisions. For example, if you try to modify a sensitive file, the system checks your authenticated user ID against the list of IDs representing users who are authorized to read and write the data in that file. Only if your ID appears in that list will the system allow you to access the file. (File access is discussed in "Data Access: Protecting Your Data" later in this chapter.)

Secure systems use your ID to maintain individual accountability–in other words, to keep track of what you're doing in a system, particularly if you're affecting security in any way. If Jack Hacke repeatedly tries to access files he's not authorized to view, the system will know! (The discussion of auditing in Chapter 6, Inside the Orange Book, describes how this tracking works.)

At one time, a system cracker would have to try to guess your password, one password attempt at a time (a so-called brute force attack). Like everything else, this process has been automated. Crackers now use computers to do the guessing. In theory, the longer the password, the longer it takes to try every combination of characters. For example, with a password containing eight random characters, there are 2,800,000,000,000 combinations; even with a computer capable of guessing one million passwords per second (a lot faster than the machine your average cracker is likely to be using!), figuring out the right combination would take an average of forty-five years.

The problem is, users don't select random, or even decently secure passwords, and a cracker doesn't need to figure out your password–any password will do. Unfortunately, users typically pick passwords that are laughably easy to guess–their initials, their childrens' names, their license plates, etc. Studies indicate that a very large percentage of users' passwords can easily be guessed. With the help of online dictionaries of common passwords (English words, names of people, animals, cars, fictional characters, places, and so on), crackers are quite likely to be able to guess a good many of the passwords most people are likely to choose. But if you select a good password (see the hints in the inset), an intruder shouldn't be able to guess it–with or without a dictionary.

Hints for Picking Passwords

If you're allowed to choose your own password, pick passwords that are hard to guess. Here are some suggestions:

The best passwords contain mixed uppercase and lowercase letters, as well as at least one number and/or special character. The password you pick doesn't need to be gibberish. In fact, if it is, you'll be tempted to write it down, defeating the purpose of your careful selection. Some suggestions are:
Your ID is associated with all of the processes you create. In many systems, you can effectively change your identity to that of another user; in traditional, untrusted UNIX systems, for example, you do this with the su command. When you change identity, the system may lose its ability to keep track of who's doing what. In secure systems, the system may still allow you to change identity, but it typically keeps track of your original identity as well, so processes you create are still stamped with your "real" ID.

Systems typically maintain a file containing information about your privileges and characteristics; in some systems, this is called a security profile, an authentication profile, or a user list. Your profile might tell the system what your clearance is (e.g., SECRET), whether you're allowed to change your own password, whether you can log in on weekends, whether you can run backup programs and other privileged programs, and a myriad of other information. In some cases, your profile is in the same file as the password list; in other cases, the information might be kept in separate files. In any case, it's vital that your system protect this information; any compromise can jeopardize the security of the entire system.

One of the important pieces of information that appears in your authentication profile or user list is an indication of what kind of user you are. Most systems support several categories of users, or roles; a typical set includes regular users, a system administrator, and an operator. Highly secure systems may define a security officer as a separate category. Each category of user has specific privileges and responsibilities–for example, specific programs the user can run. The system administrator, for example, may effectively be able to do anything in the system, including overriding or circumventing security requirements. The power of the system administrator is a major issue in secure systems; see the discussion of administrative controls and least privilege in Chapter 5, Secure System Planning and Administration.

Protecting Passwords

Access decisions are the heart of system security, and access decisions are based on passwords, so it's vital that your system protect its passwords and other login information.

Most systems protect passwords in two important ways: they make passwords hard to guess and login controls hard to crack, and they protect the file in which passwords are stored.

Protecting Your Login and Password on Entry

Most vendors offer a whole smorgasbord of login controls and password management features that the system administrator can mix and match to provide optimal protection of a particular system. Because these security features are commercially attractive and relatively easy to implement, most systems tend to have a lot of them. Examples of such features are shown in Table 3-1.

Table 3-1: Sample Login/Password Controls

Feature Meaning
System messages Most systems display welcome and announcement messages before and/or after you successfully log in. Some systems allow the system administrator to suppress these messages, because they may provide a clue to an observer as to the type of system being accessed. If an intruder dials in and finds out he's talking to a VMS system, for example, that's a valuable clue.
Limited attempts After a certain number of unsuccessful tries at logging into the system (the number can be specified by the system administrator), the system locks you out and prevents you from attempting to log in from that terminal. Some systems lock you out without informing you that this has happened. This allows for the possibility of taking evasive action–identifying the account as a suspicious one without letting you know you're under investigation.
Limited time periods Certain users or terminals may be limited to logging in during business hours or other specified times.
Last login message When you log in, the system may display the date and time of your last login. Many systems also display the number of unsuccessful login attempts since the time of your last successful login. This may give you a chance to discover that your account was accessed by someone else–for example, by noticing a login in the middle of the night or by noticing a pattern of repeated attempts to log in. If you weren't responsible for these attempts, notify your system administrator right away.
User-changeable passwords In many systems, you're allowed to change your own password at any time after its initial assignment by the system administrator.
System-generated passwords Some systems require you to use passwords generated randomly by the system, rather than relying on your own selection of a difficult-to-guess password. The VAX/VMS Version 4.3 system, and many other systems, ensure that these passwords are pronounceable. Some systems let you view several random choices from which you can pick one you think you'll be able to remember. A danger of system-generated passwords is that they're often so hard to remember that users may tend to write them down. Another danger is that if the algorithm for generating these passwords becomes known, your entire system is in jeopardy.
Password aging and expiration When a specified time is reached–for example, the end of the month–all passwords in the system may expire. The new passwords usually must not be identical to the old passwords. The system should give reasonable notice before requiring you to change your password; if you have to pick a password quickly, you're likely to pick a poor one.

In some systems, the system administrator can respond to a security breach by forcing a particular password, or all passwords, to expire immediately. This controls further access to the system until the damage can be assessed.

The system may keep track of your passwords for an extended period to make sure you don't reuse one that might have been guessed.

Minimum length Because short passwords are easier to guess than long ones, some systems require that passwords be a certain length, usually six to eight characters.
Password locks Locks allow the system administrator to restrict certain users from logging in or to lock login accounts that haven't been used for an extended period of time.
System passwords System passwords control access to particular terminals that might be targets for unauthorized use. Usually a system password must be entered before you enter your individual password.
Primary and secondary passwords Some systems require that two users, each with a valid password, be present to log in successfully to certain extremely sensitive accounts.
Dial-in password Some systems require that special passwords be used to access dial-in lines.

Protecting Your Password in Storage

Every system needs to maintain its authentication data. Typically, valid passwords are stored in a password file. This file typically is accessed only under certain limited circumstances–when a new user is registered, when you change your password, or when you log in and need to be authenticated.

Protection of passwords is extremely critical to system security. Systems commonly use both encryption and access controls to protect password data.

Most systems encrypt the data stored in the system's password file. Encryption (described in Chapter 7) transforms original information into altered information that usually has the appearance of random text. Encryption ensures that even if file security is somehow breached, the intruder won't be able to read the passwords in the file; they'll look like gibberish.

Most systems perform one-way encryption of passwords. One-way encryption means that the password is never decrypted–that is, deciphered into its original form. When the system administrator supplies you with your initial password, it's encrypted before it's stored in the password file. The original password is not preserved, not even in memory. Each time you log in and enter your password, the system encrypts the password you enter and compares the encrypted version with the encrypted password stored in the password file to be sure you've entered a valid password. Remember too that the password is never displayed on the terminal screen.

Access Controls.
Even encrypted passwords might be able to be cracked by a determined foe. Many systems store encrypted password data in files known as shadow password files, which have the most restrictive protection available in the system. In most systems, access is limited to the system administrator, usually by specifying only the administrator's ID in an access control list (ACL) on the file. (See the discussion of access control lists in the next section.)

Data Access: Protecting Your Data

The second important way in which a system provides computer security is by controlling access to the data stored in a system: Who can read your files? Who can change your files? Can you decide to share your data with other users? How does the system make decisions about access control?

If you work alone on a PC, you don't need to worry about access controls. You own all of your files, and you can read and write them as you wish. If you want to share a file with someone, you can copy it onto a diskette and hand it over.

With shared computers, it isn't as easy. As soon as you begin to work on a system that supports multiple users, you'll have to start worrying about data protection and access controls. You may not want every user in the system to be able to read your files. You certainly won't want them to change your files.

Even if you trust everyone on the system to keep away from your data, you need to protect against accidents. Suppose you and Joe Slow are working in separate areas of a shared directory. Both of you are working on the same projects, and you've both picked identical names for some of your files. With a few unfortunate keystrokes, Joe can change directories and delete one of your files, thinking it's his own. If your files aren't protected in any way, the system doesn't put any obstacles in his path. Access controls on files (they usually apply to other system objects, such as directories and devices as well) provide protection against such disasters.

There are two basic types of access controls that provide different levels of protection to the files in your system: discretionary access control and mandatory access control.

With discretionary access control (DAC) you decide how you want to protect your files, and whether to share your data. With the more complex mandatory access control (MAC) the system protects your files. In a MAC system, everything has a label. Using the security policy relationships established for your organization, the system decides whether a user can access a file by comparing the label of the user with the label of the file. The following sections introduce these types of access controls.

Discretionary Access Control

Discretionary access control (DAC) is an access policy that restricts access to files (and other system objects such as directories and devices) based on the identity of users and/or the groups to which they belong.

What's discretionary about discretionary access control? In contrast to mandatory access control, in which the system controls access, DAC is applied at your own discretion. With DAC, you can choose to give away your data; with MAC, you can't.

Not only does DAC let you tell the system who can access your data, it lets you specify the type of access allowed. For example, you might want everyone in the system to be able to read a particular file, but you might want only yourself and your manager to be able to change it. Most systems support three basic types of access:

If you have read access for a file, you can read the file.

If you have write access for a file, you can write (change or replace) the file.

The execute permission is relevant only if the file is a program. If you have execute permission for a file, you can run the program.


There are many types of discretionary access control. One simple method involves ownership of files, directories, and devices.

If you create a file, you're the owner of the file. Your login ID, or some other identifier, is entered in the file header. A system might base all of its access decisions on file ownership. If you're the owner of the file, the system lets you read and change the file. If you're not the owner, you have no rights to the file. This is a simple scheme, but not a very practical one. For one thing, it doesn't let you share the file with anyone.

Virtually every system keeps track of file ownership and bases many access decisions upon it (for example, regardless of other mechanisms, the system might let you delete a file only if you're the file owner).

File Types and File Protection Classes

File types and file protection classes provide more powerful access mechanisms. Some systems let you assign a file type or a file protection class when you create a file. You can pick from a limited set of options for file access. Many systems let you define a file as a public, semipublic, or private file. The Wang SVS/OS CAP 1.0 system provides the following choices for a file protection class:

Public. Anyone can read or write the file.

Execute-only. Anyone can execute the file (run the program). Only the file owner and the system administrator can read or write it.

Read-only. Anyone can read or execute the file. Only the file owner and the system administrator can write it.

Private. Only the file owner and the system administrator can read, write, or execute the file.

System-dependent. For example, the system administrator might set up the system so only users with access rights to class P files (defined in user profiles) may be allowed to access PAYROLL files (protected with a file protection class of P).

Self/Group/Public Controls

In many systems, you control access to your files by dividing the world of users into three categories, and telling the system what the users in each category can do to your file. Some systems call these self/group/public controls. In UNIX, they're called user/group/other (UGO) controls:

You–the creator or owner of the file.

A set of users. For example, all the users in a particular department may be in the R&D group.

Everyone else–users other than you and the other members of your group.

Each file has a set of bits called file permissions associated with it. File permissions often have the meanings shown in Figure 3-1:

Figure 3-1: Self/Group/Public Controls

If you list your files (with the correct option) in a UNIX system, you'll see such file permissions as the following:

-rw-rw-r--   1  frank   r&d   81904   Nov 7 13:25  UPDATES
If a dash (\-) appears in place of a permission, the user does not have the corresponding permission to read, write, or execute the file. For example, in the above example, the file owner (frank) can read and write the UPDATES file (rw\-), members of the file group (r&d) can read and write the file (rw\-), and the rest of the world can only read the file (r\-\^\^\-). (Ignore the first \- above; it has a special meaning to UNIX.)

Consider a few more examples:

The CHESS file contains a game; its permissions look like this:

-rwxrwxrwx   1  libr   games   61799   May 19  10:11  CHESS
Everyone can read, write, and execute this file.

The SRC95 file is a segment of code that several people in the r&d group are working on; its permissions look like this:

-rw-rw----   1  sarah   r&d   55660    Dec 19  11:42  SRC95
The owner and the other members of the group can read and change the file. No one else can access it at all.

The self/group/public controls are a good way to protect files. But what happens if you need to protect a file in different ways for different users, or if you want to keep one user from accessing a file?

If Sarah owns the FLAG file and wants Joe (a member of her group) to be able to read and change it, she'll specify the following permissions:

-rw-rw----   1  sarah   r&d   22975    Jan 19  10:14  FLAG
If Sarah wants Joe to be able to read FLAG, and Mary to be able to read and change it, she could make Mary the owner of the file (with r and w permissions) and leave Joe as a member of the group that can read (r) only. But what if Joe's group contains other users who aren't trusted enough to read FLAG? How can Sarah exclude the sinister Sam, for example?

With some complicated maneuvering, it's possible to accomplish these goals with self/group/public controls, but the more special cases you have, the more unwieldy this kind of file access becomes.

Access Control Lists

Access control lists (ACLs) are lists of users and groups, with their specific permissions. They offer a more flexible way of providing discretionary access control. ACLs are implemented differently on different systems. For example, in a UNIX-based trusted system that uses the UNIX security kernel developed by Atlanta-based SecureWare, you'd protect PAYROLL with ACLs in the form:

‹john.acct, r›

‹, rw›
where: If john is in the acct group, he can only read the file. If he belongs to any other group, by default he has no access. Similarly, if jane is in the pay group, she can read and write the file. Figure 3-2 illustrates how ACLs control file access.

Figure 3-2: Discretionary Access Control With an Access Control List

ACLs usually support wildcard characters that let you specify more general access to files. For example, you might specify:

<*.*, r>
to indicate that any user (*) in any group (*) can read (r) the file. You might specify:
<@.*, rw>
to indicate that only the owner (@) of the file can read (r) and modify (w) it.

In some systems, you can indicate that a particular user is specifically not allowed to access a file–for example, by specifying a null character or the word none or null) in place of an access character such as r or w.

‹sam.*,none ›

Mandatory Access Control

Mandatory access control (MAC) is an access policy supported for systems that process especially sensitive data (e.g., government classified information or sensitive corporate data). Systems providing mandatory access controls must assign sensitivity labels to all subjects (e.g., users, programs) and all objects (e.g., files, directories, devices, windows, sockets) in the system. A user's sensitivity label specifies the sensitivity level, or level of trust, associated with that user; it's often called a clearance. A file's sensitivity label specifies the level of trust that a user must have to be able to access that file. Mandatory access controls use sensitivity labels to determine who can access what information in your system.

Together, labeling and mandatory access control implement a multi-level security policy–a policy for handling multiple information classifications at a number of different security levels within a single computer system.

In the past, military systems were set up to handle one, and only one, level of security. The policy for such systems, known as a system high policy, required everyone who used the system to have the highest clearance required by any data in the system. A system that handled SECRET data, for example, could not be used by anyone who did not have a SECRET clearance (regardless of how well protected the SECRET data was). Although many government sites still operate in system high mode, others support multiple security levels. This is done by dividing, or compartmentalizing, the data. Such systems support simultaneous use by users with the highest and the lowest clearances (or, potentially, with no clearances at all), and with access to many different types of sensitive compartmented intelligence (SCI). (Compartments are introduced in the next section.)

Although this section tries to touch on the major issues involved with labeling, security levels, and mandatory access control, these are complicated topics, with a lot of security history behind them. Chapter 6, Inside the Orange Book, discusses briefly how the Orange Book specifies requirements in these areas. If you need to know more, consult some of the more technical books referenced in Appendix E, A Security Source Book.

Sensitivity Labels

Every subject and object in a system supporting mandatory access controls has a sensitivity label associated with it. A sensitivity label consists of two parts: A classification and a set of categories (sometimes called compartments). For example:

The classification is a single, hierarchical level. In the so-called military security model (based on the Department of Defense multi-level security policy), there are four distinct levels:

Each classification is more trusted than the classification beneath it.

The actual definition of classifications is up to a site's system administrator or security officer. If your site is processing government classified information, your labeling setup will have to support the military model. But in general, labels represent whatever set of classifications and categories make sense in your own environment. For example, at a commercial site, you might define the following corporate hierarchy:

Or you might define gradations in levels of trust:
The categories or compartments are nonhierarchical, and represent distinct areas of information in your system. Together, the categories make up a category set or a compartment set. A set may contain an arbitrary number of items.

In a military environment, you might have categories such as:

In a commercial environment, your categories might correspond to company departments, product names, ad campaigns, or any other setup you wish to implement:
The idea is that even someone who has the highest classification isn't automatically cleared to see all information at that level. To see information in the SDI category, for example, you must "need to know" that information. The section entitled "Access Decisions" in this chapter describes how a system determines whether you can access a particular piece of information.

Data Import and Export

In a mandatory access control system, it's very important to control the import of information from other systems, and the export of information to other systems. MAC systems have a lot of rules about data import and export. They also control which system devices you can use to copy and print information; for example, you might not be allowed to print sensitive information on a printer located in a public area of your building. There are also rules for labeling devices and printed output (with banner pages and page headers and trailers). The discussion of specific labeling requirements in Chapter 6, Inside the Orange Book, touches on some of these rules.

Access Decisions

In a mandatory access control system, all access decisions are made by the system. Unlike discretionary access control, which allows you to specify, at your own discretion, who can and cannot share your files, mandatory access control puts all such access decisions under the control of the system. The decision to allow or deny access to an object (e.g., a file) involves an interaction between all three of the following:

When you try to read the LOGISTIC file, the system compares your clearance to the file's label to determine whether you'll be allowed to read it. Figure 3-3 shows how mandatory access control works.

Figure 3-3: Mandatory Access Control

Although multi-level security systems provide many benefits, they're the source of many frustrations as well. If you're beginning to use a system that supports labeling and mandatory access controls, you may find yourself frustrated by trying to read and write files. For example, under some circumstances, you may write a file and then find that you can't read it! Basically, mandatory access control comes down to the read and write rules described below.

To read an object, the subject's sensitivity level must dominate the object's sensitivity level. Dominate? What that means is that to read the LOGISTIC file (whose label is SECRET [VENUS ALPHA]), your classification must equal or exceed SECRET (it must be SECRET or TOP SECRET). In addition, the categories you're allowed to read must include the categories specified in the file label. In this case, suppose your clearance includes three categories: VENUS, TANK, and ALPHA. You'll be able to read LOGISTIC because its label contains only VENUS and ALPHA.

But suppose your clearance is CONFIDENTIAL [VENUS ALPHA]. No good! Your classification isn't high enough. It must be SECRET or TOP SECRET.

Now suppose your clearance is TOP SECRET [\s-1VENUS\s+1]. Still no good! Your classification is high enough, but to read LOGISTIC you need clearance to the ALPHA compartment as well.

To write an object, the object's sensitivity level must dominate the subject's sensitivity level. To change any information in the LOGISTIC file, your sensitivity level must equal or be less than the sensitivity level of the file, and your categories must all be included in the file's category set. Because your label is TOP SECRET and the file's is SECRET, you can't change the file.

This write rule may seem odd. Does this, in fact, mean that you're too trusted to change the LOGISTIC file? Shouldn't it work the other way? That is, shouldn't TOP SECRET users be able to change SECRET files? Well, no. The reason has to do with something called a downgrade of information, or a write-down of information. Sometimes security people talk about information flowing to a lower or a higher level.

Consider the case where a user with a TOP SECRET clearance reads a number of TOP SECRET documents and tries to copy sections of them into an UNCLASSIFIED memo. That would be a downgrade of information (TOP SECRET information becoming UNCLASSIFIED), and it's not allowed because it would provide a way to share highly sensitive information with people not authorized to access it.

The other side of the write rule is known as upgrade of information. Suppose you have a CONFIDENTIAL clearance. The system will let you write a SECRET memo, but then it won't let you read the memo. Why? By writing CONFIDENTIAL information into a SECRET memo, you've essentially made that information SECRET. The system does allow an upgrade of information, but it doesn't suspend the normal access rules.

Note that these rules become substantially more complicated when your system supports information labels as well as sensitivity labels. Information labels are required for compartmented mode workstations, a technology described in Chapter 6, Inside the Orange Book.

In the previous example, the label:

is "higher" than either of the labels:

But you can't really say that the label:
is higher than the label:
Because neither label contains all the categories of the other, the labels can't be compared. They're said to be incomparable. In a mandatory access control system, you won't be allowed access to a file whose label is incomparable to your clearance.

Bell-LaPadula Model.
It's important to note the origin of the policies outlined above. In 1973, David Bell and Leonard LaPadula first described the DoD multi-level military security policy in abstract, formal terms, as mentioned in Chapter 2, Some Security History. In the Bell and LaPadula model, they used mathematical notation and set theory to define the concept of a secure state, the modes of access, and the rules for granting access. They called their model the Basic Security Theorem. In their model, Bell and LaPadula defined the read and write rules we've simplified above. The simple security condition stated that the subject's sensitivity label must dominate the object's sensitivity label (the read rule we previously described). The *-property, or star property stated that the object's sensitivity label must dominate the subject's sensitivity label (the write rule we previously described). Several of the more technical books referenced in Appendix E, A Security Source Book, describe these rules more rigorously. Refer to them for additional details.

Back to: Computer Security Basics

O'Reilly Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
International | About O'Reilly | Affiliated Companies

© 2001, O'Reilly & Associates, Inc.