Why Capabilities and Persistence are Essential
Fri, 12 Nov 1999 11:06:33 -0800
At 11:52 PM 11/11/1999 -0800, firstname.lastname@example.org wrote:
>In the technical sense, mandatory policies are applied system-wide and
>are relatively static. Discretionary policies are available to users
>and must be able to be applied flexibly and on an as-needed basis.
>>From the point of view of a program or process, it doesn't really care
>what the structure is of the limitations imposed on it from the outside.
>It may limited by system-wide mandatory policies, or by user-imposed
>discretionary policies. It doesn't matter.
I don't know many systems (EROS and KeyKOS being the notable exceptions)
where discretionary policy can be applied by users to the programs they
run. Most systems only allow such policy to be applied to other users (via
ACLs). The ability of users to apply policy to the programs they run would
go a long way toward controlling the spread of viruses and worms.
Consider Microsoft Word for example. Here is a program which, via macro
viruses, is a rich breeding ground for various system penetrations. If we
could run Word in a controlled box, we could divide the storage used by the
program into several useful boxes.
There is the read-only stuff (probably including the binary for the
program), which we would set up so Word itself could not change it.
There are the libraries of styles, fonts, etc. which apply to more than one
document. We would set those up so if Word attempted to change them, part
of the TCB we use to run word would ask us for permission for each change.
(Or if that results in too many dialog boxes, for each session.)
There is the permanent storage associated with each document. This storage
would be read-write (unless the document itself was read only).
Finally there is the working storage Word uses (main storage and scratch
files). It would always have free access to this class of storage.
This approach illustrates a difference I have with something Jonathan
posted earlier (and I am too lazy to dig back and quote). He indicated
that as security professionals, it is our job to build systems that protect
the user. I take a slightly different view of what our job is. It is to
build systems where the implications of a user's security decision are
readily apparent. The user (and in the case of corporate computing, the
system management) are the only ones who can set policy. We as security
professionals can only provide tools for implementation and/or reasons why
the policy is impossible.
If we take the physical world as an example, we can look at locks on doors.
It is quite apparent the risks I take leaving the door to my house
unlocked. However I have a free choice about what policy I implement on
that door. I know people who keep their doors locked all the time, keep
them locked only when they aren't home, and never lock them.
If we can figure out how to build systems where it is clear to the user the
things that programs they run can do, then we will have gone a long way to
making computers as easy to set policy for as houses.