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