Operating C. Weissman

Systems Editor

A Note on the

Confinement Problem

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 Words and Phrases: protection, confinement,

proprietary program, privacy, security, leakage of data

CR Categories: 2.11, 4.30

Introduction

Designers of protection systems are usually pre-

occupied with the need to safeguard data from un-

authorized 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 controlled environment within which another, pos-

sibly untrustworthy program, can be run safely [1, 2].

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, he will 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

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.

Author's address: Xerox Palo Alto Research Center, 3180 Porter

Drive, Palo Alto, CA 94304.

proprietary program or may have its own private data.

These things, while interesting, will not concern us here.

Even when all unauthorized access has been pre-

vented, 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, have the property that the dissatisfied cus-

tomer 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 regards as con-

fidential, there will generally be no indication that the

security of the data has been compromised.

There is, however, some hope for technical safe-

guards 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 de-

scribe methods for blocking some of the subtle paths

by which data 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 in preparation 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 which cannot be forbidden without

imposing an unreasonable constraint on the computing

which a service can do) and grant its owner access to

this file. If he tests for its existence at suitable intervals,

he can read out the data before the service completes

its work and the file is destroyed.

3. The service may send a message to a process con-

trolled by its owner, using the system's interprocess

communication facility.

4. More subtly, the information may be encoded in the

bill rendered for the service, since its owner must get a

copy. If the form of bills is suitably restricted, the

amount of information which can be transmitted in this

way can be reduced to a few bits or tens of bits. Re-

ducing it to zero, however, requires more far-reaching

measures.

613

Communications October 1973

of Volume 16

the