A Note on the Confinement Problem

Service is the "to-be confined" program.

Customer makes calls to the service.

Service should not be able to modify customer data.

Confinement is about preventing leakage of information by the service to other programs.

Examples of leakage:

1) service accumulates data in memory, and leaks to caller.

2) store leaked info in a temp file

3) send leaked info via interprocess communication

4) leak info in "bill" for service

5) use "interlocks" -- ie if only one process is allowed to write a file at a given time, but have any number of readers, this capability in itself can be used to leak info with three files: data, writeclock, and readclock (see paper for details)

6) service varies ratio of computing to i/o or paging rate -- i.e. use covert channels

Confinement rules: (how to confine a program)

1) Confined program must not be allowed to use memory across calls.

2) Total isolation: a confined program cannot make calls to any other program.

But the supervisor (OS) must use memory, so is this practical?

Ok... but the supervisor can be trusted.

Transitive confinement: if a confined program calls another program which is not trusted, the called program must be confined.

So confined programs can only call trusted programs or other confined programs.

A trustworthy program must guard against leakage (by human certification). How to ensure this? Need to eliminate channels that can be used for leakage: storage, legitimate channels (i.e. bill), covert channels. (today: network should also be one)

Caller needs to block / eliminate all these legitimate and covert channels from leaking information.

Masking: A program to be confined must allow its caller to determine all its inputs into legitimate and covert channels. We say that the channels are makes by the caller.

Enforcement: The supervisor must ensure that a confined program's input to covert channels conforms to the caller's specifications.

(Can be done by slowing program down, generating spurious disk refs, etc.)

Paper seems to mostly be concerned about leakage in a timeshared system. (Makes sense; paper was written in 1973.) Today, leakage via network communication is much more serious a problem and is why people use programs like personal firewalls to prevent such problems.