▶ 3.5 File Security Controls
Let us look at the access permissions required to implement the user isolation policy for Bob’s tower computer. The policy appears in Tables 3.3 and 3.4. First, let us look at access rights for executable programs. FIGURE 3.12 illustrates the appropriate access rights, using two executable files as examples. Regular users receive Read and Execute access. The “System” user receives full access to the file.
FIGURE 3.12 Access rights to executable files.
FIGURE 3.13 uses a slightly different approach to show access rights to user files. Instead of showing example files, it shows a “pile” of files to represent those belonging to the two regular users.
FIGURE 3.13 Access rights to personal files.
The two diagrams represent all of the users on Bob’s system. In larger systems, we might use a single oval to represent all “regular” users and present permissions in those terms. We also could represent permissions with separate ovals to represent “the file owner,” the “system,” and “other users.”
3.5.1 File Permission Flags
Real systems rarely use diagrams to establish access rights; instead, there is a notation or a tabular format to use. The simplest approach is to provide a set of permission flags to identify rights for a specific set of users.
In FIGURE 3.14, we have three sets of flags. Each set specifies the basic rights of Read, Write, and Execute (or Seek for directories), and it associates the rights with one of three specific classes of users:
Owner rights: the user who owns the file in question
System rights: privileged processes run by the system
World rights: all users other than the owner and the system
FIGURE 3.14 A set of file permission flags.
This allows us to define access rights with a compact set of nine flags, along with the user identity of the file’s owner.
Because the operating system already keeps track of the owner of every file and other major resources, our solution doesn’t need to explicitly identify users. All it needs to do is identify the rights granted to the owner, the system, and the rest of the user community (the “world”). A user with administrative rights receives “System” access rights to files and resources. Most systems also can grant access rights to predefined “groups” of users. We will discuss that in Chapter 4.
Although we’ve reduced the rights to a very compact set, they still carry a great deal of redundancy. Typically, owners get full access to their files. Administrators and privileged user identities associated with system operations, like a “System” user, typically get full access to everything. The important differences in access rights arise when we specify access rights for the rest of the user community.
In most examples and exercises in this chapter, we use a simplified set of rights called compact access rules. FIGURE 3.15 illustrates such a rule.
FIGURE 3.15 Flags for compact access rules.
We abbreviate a compact access rule with three letters. As shown in Figure 3.15, the letters represent read, write, and execute rights. Thus, the permission R-E allows read and execute to other users, while --- allows no access to other users.
System and Owner Access Rights in Practice
If our examples omit owner and system access rights, we should ask some obvious questions: Why would any system allow us to specify owner and system access rights? Why would we ever want to restrict access by a file’s owner or by the system? The answer is, of course, Least Privilege. Access restrictions sometimes make sense for individual owners or for the overall system.
Operating systems are large and complex, so Least Privilege helps keep components from injuring one another. Early versions of the Unix system, for example, ran most system processes with the “root” user identity. As discussed earlier in this text, this led to disaster when the Morris worm hit. Modern Unix systems, and their derivatives like MacOS and Linux, run as few processes as possible using the “root” user identity.
When we create a new file on Microsoft Windows, it will, by default, be accessible by the “SYSTEM” user identity and by administrators. We can remove those permissions and still, as the owner, read and write the file. The access permissions apply to any processes that belong to the “SYSTEM” user identity, while the true “kernel” of the operating system is not really restricted by such rules. Thus, we can still read and write our file even though “SYSTEM” processes cannot.
On some high-security systems, the security policy forbids administrators to look at certain types of sensitive information stored on the computer. Such systems should block access to that information, even when using a “SYSTEM” user identity, unless the specific individual is allowed to use the sensitive data. Thus, some administrators may be able to look at the highly sensitive data while others are blocked from that data.
In this chapter, we focus on simple cases and assume that both the file’s owner and the system have full access rights to it. The only access rights we need to specify are for “world” access to files.
3.5.2 Security Controls to Enforce the Isolation Policy
The diagrams are useful to illustrate how users can (or can’t) share information on the system. To implement a policy, we produce a more detailed list of security controls. Bob’s isolation policy, described in Tables 3.3 and 3.4, requires some general security controls and some specific access rules. These appear in the following tables.
First, we specify the general security controls in TABLE 3.6. These controls establish user identities and passwords on Bob’s computer. These controls follow the format introduced in Section 2.6.
TABLE 3.6 Security Controls to Implement the Isolation Policy |
|---|
|
To specify access rules, we need a different format. We will use a simple format that makes use of compact access rules; it lists the three-letter abbreviation for the “World” access rights, and it also identifies the file’s owner. TABLE 3.7 lists the access rules.
TABLE 3.7 Compact Access Rules for the Isolation Policy |
|---|
|
Note that the “File owner” column does not consistently refer to Bob, even though he is the owner of the computer. The column indicates the computer user that owns the particular file. These rules assume Bob logs in as the user “bob” and that Alice logs in as “alice.” If Bob always logs in as an administrator, then he gets “System” access rights, which gives him access to every file on his computer.
3.5.3 States and State Diagrams
States and state diagrams give us a different way of organizing and looking at parts of a complex system. While we can always look at a system by breaking it into pieces and examining individual parts, a state diagram gives us a systematic way to break up its behavior.
Engineers apply state diagrams to all kinds of systems. At the circuit level, engineers can implement a diagram directly in hardware. At the system level, states and state diagrams provide a way to break complicated system behavior into separate and more comprehensible activities.
The individual “states” reduce the system’s behavior into a manageable number of separate situations. The state diagram gives us a simple image of how the system behaves. For example, FIGURE 3.16 presents a state diagram for a door.
FIGURE 3.16 State diagram showing a door’s operation.
To create a state diagram, we look at the system and divide its behavior into a small number of completely separate conditions. Each condition becomes a “state.” Then we identify events that take place, especially those that cause the system to change from one state into another.
In Figure 3.16, we have two states because a door can only be “Open” or “Closed.” We have three possible events: knocking, opening, and closing. The door actually changes state when we open or close it. Knocking causes no change at all.
For the state diagram to be useful, it must capture all relevant and possible events, especially those that change states. Figure 3.16 presents a very limited view of a door, because it says nothing about locking or unlocking, or even about responses to knocking. In fact, knocking is clearly unnecessary, because the diagram shows that the door opens and closes regardless of whether knocking took place.
Information States
We also talk about data or information as having states. Here are the fundamental information states:
■ Storage state—the information is stored and is not currently being processed. We also call this state “data at rest.”
■ Processing state—the information is being used by an active process to make decisions or to transform the information into another form. This is “data in use.”
■ Transmission state—the information is being moved from one storage area to another. This is “data in motion.”
FIGURE 3.17 shows a state diagram for Bob’s essay file. We initially create files in an application program, so Bob creates it in the Processing state. When he saves the file, he puts it into the Storage state. If he moves it onto a removable drive, it enters the Transmission state.
FIGURE 3.17 Information states of the essay file.
In this diagram, we process either new or stored data. We save the result as stored data. We don’t use processing to transport data; we simply move the data to a portable medium. In this environment, data never moves directly from the Processing state to the Transmission state.
A closed door has different security implications than an open one. The same is true for information states. Each reflects a different access control environment. The storage state involves files and their access rights. The processing state refers to the world of processes and RAM-based access control.
When we transmit information between programs or processes inside an operating system, the storage and processing controls protect those operations. When we move a file to removable storage, like a USB drive, we move it away from the protections enforced by our operating system. This also happens when we transmit information across a network.