SECURITY - security features of the secure command loader.

The stock GCOS-8 permission structure associates permissions with users. The UW Tools command loader CMDL associates permissions with programs. This write-up explains the differences between the two approaches and why the second approach gives added security.

When permissions are associated with users, administrators are in an "all or nothing" situation. A particular permission bit (LODS, CARDIN, etc.) allows users to perform a large number of privileged operations. If a user has a legitimate reason for performing a single operation, the administrator must decide whether or not to give the user the associated permission. The administrator can either refuse the permission (and prevent the user from getting the job done) or grant the permission, thereby giving the user permission to do many many things that may not have anything to do with the user's legitimate work.

Another security problem associated with personal privileges is known as the "Trojan Horse" problem. It works like this: an unprivileged user writes a useful utility and makes this available to the user community. Sooner or later, a privileged user will try the utility. This is what the utility has been waiting for. When the utility finds out that it has inherited privileges from its privileged user, it uses those privileges to break system security. This can happen completely without the privileged user's knowledge.

If, on the other hand, privileges are associated with programs instead of users, system administrators can keep a firmer grasp on the situation. When a user has a legitimate reason to perform a privileged operation, the administrators grant appropriate permissions to a program that performs this operation and give the user permissions to execute that program. They do not give the program any permissions until the program can be certified as "trustworthy" -- it does its job and only its job. The user can call upon the program for this one particular operation and does not have the ability to perform any other operations associated with the permission.

Permissions are never given to programs until the programs are verified as "safe". Once this has been done, individuals can be given permission to use a privileged program through the standard file system permission system: give the user "Execute" permission on the file that contains the program.

Programs are given permissions using the UW Tools version of ACCESS. For example,

access mf /prog subsys/jrn/

gives the permissions of the JRN subsystem to program "/prog". (JRN is allowed to use DRL T.CMOV.) For more information, see "expl access mf".

The "subsys/xxxx/" attribute will only be honoured, if the user already has LODS permssion, or if the program file is from the top level of one of the two special userids. One of these is always "cmdlib". The other is usually "uw_priv", and is used for system maintenance utilities. Permissions on these two userids must be tightly controlled by the administration. Since programs under these userids automatically have full permissions, anyone with the ability to write to these accounts can grab whatever permissions he or she chooses.

Notes:

Installing CMDL essentially gives every user LODX permission, in that it allows them to execute their own programs directly. There is no loss of security, since users could always execute their own programs through commands like FRN. In fact, there is an increase in security, since it frees the LODX permission bit for other meanings. For example, at Waterloo, LODX was given to users who were allowed to log in from the public X.25 networks.

Copyright © 1996, Thinkage Ltd.