Safety's Security Policy

The following is offered by way of explaining some of the philosophy of
what Safety does in system security.

The security parts of Safety are designed to address the observation that
while military security policy has dealt with clearing PEOPLE for access
to information, what is needed is clearing ACTIONS (or, if you prefer the
word, ACTIVITIES). In the human and paper world, actions tend to be hard
to define, and a degree of trust must be present that people given access
to some secret information will use it responsibly for the reasons access
was given.

Computers lack such "common sense", but also actions that computers take
can often be characterized more precisely than human ones.

Safety was devised because I have observed that one often wants or needs
certain actions to be performed, but other actions need not be. Where vital
data to a company is stored on and used on computers, and must be accessed
by more than one person, it is useful to be able to control the actions
on that data more finely than simply a go/no-go based on a person's identity.

The view of user actions from an operating system perspective is in some ways
coarse grained, but there are some things that can be known; Safety takes
advantage of some of these and allows you to distinguish an action you want
to authorize on your sensitive data and one you do not.

There are of course problems of aggregation, which are similar to those of
covert channels in the Multilevel Security world. In the MLS world, one
bandwidth limits covert channels. To a degree you bandwidth limit aggregation
here. I am not however proposing that Safety is a perfect or ultimate system.
Rather, it is a system that addresses authorizing actions to a point, instead
of ignoring the problem.


A few example illustrations may help here.

Let's say you have a customer list file. It is normally maintained by
some accounting applications you have, and any of several clerks ought
to be able to access it in the course of their taking orders, shipping
items, and so on, and likewise some sales folks should be able to look
for prospects.

Still, you don't want this to get to a competitor.

In a vanilla OS, you'd have to allow the clerks, sales folks, etc., R/W
access to this file, which would mean anyone might copy or possibly
trash it. If all access is via ONE program, you might use a subsystem
facility to limit access, but where multiple programs are used, this gets
harder, and you have to ensure somehow that only a set collection of users
can access the file...and you may also want to prevent someone who tries
the access at 3AM from succeeding regardless.

That's the point of having a number of checks on access. Safety will let
you limit access by time of day and location, by person, AND by what
programs are in use, and can even, if you like, deliver a fake file
to someone who tries to make an illicit copy of the data, instead of
giving a possibly-revealing error message. This means that someone might
try to bribe a clerk, but the clerk can only look at records one at a time
using his program...and cannot use COPY to copy the whole thing. A salesman
about to leave for another company is similarly inhibited. And you can
inhibit someone who might have gained system privileges from access to the
file at all when those privileges are available to him.

Actions are represented for the computer by a program accessing a given
file or files, on behalf of some defined user, with at most some defined
privilege set, at some place and/or time. (There is also provision for
ensuring the programs or scripts being used have not been tampered with.)

This is the model used to control what can be done with key corporate
information. You allow actions to be taken, and do not have to permit
access wholesale to people.

This has other benefits. Consider what happens when someone uses downloaded
code (as happens with some web browsers) which has a security hole. The person
running the browser is treated as the person on whose behalf this
downloaded code is run...so the security hole might be used to read or 
possibly write anywhere that individual is permitted.

Where critical data cannot be accessed because this action is not authorized,
it is protected from such abuse regardless of the browser or unknown code.

Beyond this, Safety has a "paranoid mode" which can be enabled where it
is suspected downloaded code will be used. The supplied scripts will 
simply notify the user of any files accessed while in this mode, but they
can also be edited to permit veto of opens based on any criteria a user
wants....thus restricting access to places a user considers safe. With
such a system in place, security holes in browsers and similar downloaded
code are less a problem, since their effect is limited to only a few
parts of a user's normal access domain.

Glenn C. Everhart