o Viaje 2, Economía promedio de combustible :

A protected subsystem is an application program outside of the operating system that carries out functions for a group of users, maintains some common data for all users in the group, and protects the data from improper, access by users in the group. The subsystem itself is protected from tampering. A database management system that maintains a database shared by a group of users is a protected subsystem. The operating system, via conventional access controls, prevents users from tampering with either the database or the DBMS itself. The database can only be accessed through proper calls to the DBMS. Most transaction monitors are also subsystems. A program such as a compiler is not a subsystem because the compiler runs with the access rights of the user that called if, operating on data accessible only to that user.

Smith process Green process Jones process DBMS process DATABASE ALPHA (Smith) DATABASE BETA (Smith,Green) DATABASE GAMMA (Green,Jones)

Figure 11-1. Protected Subsystem in an Active Process. In this structure, the DBMS

runs as a process that is inherently no different from a user process. The operating system’s normal access-control mechanism prevents all but the DBMS process from accessing the database files. The DBMS must control individual users’ access to different files and different portions of files.

One key problem in supporting a protected subsystem is how to prevent user programs from accessing the subsystem’s shared data directly, while allowing the subsystem access to the data. In most systems, the easiest way to implement such a scheme is to run the subsystem in its own process with its own access rights and its own files (fig. 11-1). User processes send requests to the subsystem via shared memory or interprocess messages. The subsystem remains permanently active, ready to process a request at any time.

When subsystems are supported in individual processes, they tend to require centralized system management to ensure that they are always active. Users cannot write their own subsystems and change them as they see fit. But these management problems are not as important a consideration as a security problem: the operating system cannot tell on whose behalf the subsystem is working at any given time. The subsystem is responsible for enforcing access to data belonging to a number of users, even though the subsystem is apt to be far less trustworthy than the operating system. As far as the operating system is concerned, all files used by the subsystem belong to a single user (DBMS, in figure 11-1). The security controls in the operating system only keep the subsystem’s database separate from other processes.

A related way to support subsystems, employed in Unix via its set-uid mechanism, involves activating a separate subsystem process on each request made by another process (fig. 11-2). The subsystem process runs with the identity of the subsystem and not with the user’s identity: At any one time, multiple subsystem processes may be operating on common data. This technique has all the same security problems as the single process, because each of the multiple processes takes on the identity of the same user, but it does minimize the need for centralized management of subsystems.

In yet another approach, the subsystem runs as just another program in the context of each process that uses it, thereby taking advantage of the operating system’s process isolation mechanisms to separate the actions of different users. In order to prevent the applications fro damaging the subsystem’s data, this approach requires a machine whose hardware supports hierarchical domains (see section 8.4). The subsystem runs in an inner domain that is more protected than the user program but less protected and less trusted than the operating system. The subsystem must still be trusted to manage data shared among several users, but the operating

Smith process Green process Jones process DBMS process DBMS process DBMS process DATABASE ALPHA (Smith) DATABASE BETA (Smith,Green) DATABASE GAMMA (Green,Jones)

Figure 11-2. Protected Subsystem Activated on Request. The subsystem is

activated as a separate process each time it is needed, while retaining its own identity separate from that of the invoking process.

system can enforce a certain degree of control over the data: the data can be protected from processes outside a given group of users as well as from programs running in domains less privileged than that of the subsystem.

The maximum number of domains in a system that contains hierarchical domains is usually limited to a small number such as 3, 4, 7, or 16. As illustrated in figure 8-5, domains tend to be reserved for specific functions-the innermost ones for the operating system, the outermost ones for users, and some intermediate ones for subsystems. Recall that access control to files is based on the user identifier of the process and on the domain in which the process is running; there is no further distinction among programs within the same domain.

This structure works very well when the system supports just one or two subsystems, since each can run in its own domain. But with a limited number of domains, the use of subsystems must be centrally managed; and in a large system with scores of subsystems, there are too few domains. If several subsystems are placed in the same domain and are used by the same process, the operating system or hardware cannot distinguish between the programs of one subsystem and those of another. In figure 11-3, both the MAIL and DBMS subsystems run in the same domain. If both subsystems are used by process P1, they share the same user identifier, SMITH; therefore, both have access to the same files. Where two subsystems are mutually suspicious this is a security problem. There are several ways around this problem (Schroeder 1972), but none is very attractive. While it nicely addresses the performance problems of the other approaches, the use of hierarchical domains for subsystems can only succeed in a few special cases and is not a general solution.

OPERATING SYSTEM OPERATING-SYSTEM DOMAIN DBMS MAIL PRIV SUBSYSTEM DOMAIN

P1 P2 P3 USER DOMAIN SMITH JONES GREEN

Process P1

Figure 11-3. Mutually Suspicious Subsystems. Process P1, with access rights of

user SMITH invokes both the DBMS and the MAIL subsystems. The subsystems run as part of process P1, but in a more privileged subsystem domain. The access rights of a program in the subsystem domain run by P1 are based on the same identifier SMITH so there is no way for the DBMS subsystem to protect itself from the MAIL subsystem. This is a classic problem with hierarchical domains.

Hierarchical domains are poor vehicles for protected subsystems because there is, in general, nothing hierarchical about access rights of different subsystems. We need a more generalized domain structure, where subsystems run in private domains that are isolated from each other and from their callers, and where no practical limit constrains the total number of domains on a system. This need has driven many researchers to design hardware that can support a generalized domain or capability architecture (see section 11.6), and a few commercial systems have been built around this concept. The IBM System/38 and Intel iAPX 432 are examples. But the

hardware designs are more radical, and little experience has been accumulated in building secure operating systems on these machines. Such domain machines are viewed in practice as offering a means to improve software reliability, because a software problem in one domain cannot affect software in another domain. Building a secure operating system or security kernel on such a machine remains an area of research.