Problema del confinamiento

A Note on the Confinement Problem1
Butler W. Lampson Xerox Palo Alto Research Center

This note explores the problem of confining a program during its execution so that it cannot transmit information to any other program except its caller. A set of examples attempts to stake out the boundaries of the problem. Necessary conditions for a solution are stated and informally justified. Key Wordsand Phrases: protection, confinement, proprietary program, privacy, security, leakage of data CR Categories: 2.11, 4.30

Introduction
Designers of protection systems are usually preoccupied with the need to safeguard data from unauthorized access or modification, or programs from unauthorized execution. It is known how to solve these problems well enough so that a program can create a controlledenvironment within which another, possibly untrustworthy program, can be run safely [1, 21. Adopting terminology appropriate for our particular case, we will call the first program a customer and the second a service. The customer will want to ensure that the service cannot access (i.e. read or modify) any of his data except those items to which he explicitly grants access. If he is cautious, hewill only grant access to items which are needed as input or output for the service program. In general it is also necessary to provide for smooth transfers of control, and to handle error conditions. Furthermore, the service must be protected from intrusion by the customer, since the service may be a proprietary program or may have its own private data. These things, while interesting, will notconcern us here. Even when all unauthorized access has been prevented, there remain two ways in which the customer may be injured by the service: (1) it may not perform as advertised; or (2) it may leak, i.e. transmit to its owner the input data which the customer gives it. The former problem does not seem to have any general technical solution short of program certification. It does, however, havethe property that the dissatisfied customer is left with evidence, in the form of incorrect outputs from the service, which he can use to support his claim for restitution. If, on the other hand, the service leaks data which the customer

1

This note originally appeared in Communications of the ACM, 16, 10 (Oct. 1973), pp 613-615. Copyright © 1973, Association for Computing Machinery, Inc.General permission to republish, but not for profit, all or part of this material is granted provided that ACM's copyright notice is given and that reference is made to the publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Computing Machinery.

A Note on the Confinement Problem

1

regards as confidential, therewill generally be no indication that the security of the data has been compromised. There is, however, some hope for technical safeguards which will prevent such leakages. We will call the problem of constraining a service in this way the confinement problem. The purpose of this note is to characterize the problem more precisely and to describe methods for blocking some of the subtle paths by whichdata can escape from confinement.

The Problem
We want to be able to confine an arbitrary program. This does not mean that any program which works when free will still work under confinement, but that any program, if confined, will be unable to leak data. A misbehaving program may well be trapped as a result of an attempt to escape. A list of possible leaks may help to create some intuition inpreparation for a more abstract description of confinement rules. 0. If the service has memory, it can collect data, wait for its owner to call it, and then return the data to him. 1. The service may write into a permanent file in its owner's directory. The owner can then come around at his leisure and collect the data. 2. The service may create a temporary file (in itself a legitimate action...