At 11:52 PM 11/11/1999 -0800, hal@finney.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.