The need for invoke: background and history

invoke is a general-purpose front-end for applications that need to manipulate protected files. The obvious example in a federal court would be the various UNIFY-based applications used for case management, case assignment, and so forth. These applications account for our heaviest use of invoke and will get the most attention in this discussion.

However, it is important to note that many other types of applications also involve protected files and require features like those provided by invoke. As an example, consider briefly the Source Code Control System provided with System V UNIX.

The purpose of SCCS is to keep an audit trail of changes to documents. Every change is recorded, when it was made and who made it, and any version of the document that ever existed can be reconstructed at any time.

What SCCS and the court UNIFY applications all have in common is the need to provide controlled access to files. Users can run the application programs and enter or query data as the programs permit, but should not simply bypass the programs and examine or change anything at will.

Such applications can, and often do, contain very elaborate and sophisticated features to control which operations are or are not permitted to which users. Such features can give an impression of great security, and they can be just as secure as they look. However, they can also be just for show, if one critical point is overlooked.

The critical point is: if features built into a program or set of programs are supposed to control a user's access to a file, that program or set of programs must be the user's only way to get at the file! To anyone who is not running the right programs, the files must be completely inaccessible.

Clearly, no program can achieve this monopoly on its own; the operating system itself must cooperate by denying file access to anyone who chooses not to use the program. UNIX usually decides users' access to files without considering what programs the users are running, but it can provide the needed enforcement when requested. The enforcement is provided through effective user/group IDs, and must be requested by using set-user-ID and set-group-ID flags. If these features are used as intended, the security controls built into the applications will have substance; otherwise, they can lead only to a dangerous false sense of security.

For more information on effective IDs and set-id flags, see the Intro(2), chmod(2), and exec(2) sections in your UNIX Programmer's Reference, and reputable books on UNIX system administration and security, such as Spafford and Garfinkel.

For UNIFY applications such as ICMS or Case Assignment, the procedures necessary to support the application controls are found in Section 10.6 of the UNIFY Developer's Reference Manual. Every court systems manager should completely understand this section, following up unclear points in other references if necessary.

There is a drawback to the procedure suggested by UNIFY: if a court has several different UNIFY applications, there must be several different copies of all of the UNIFY executables. (Each application should have its own ID, since giving a user permissions in one application should not also give the user access to some other, unrelated application. For each application ID, there needs to be a complete set of UNIFY executables owned by that ID.)

A somewhat refined approach to the problem is suggested by the authors of SCCS and can be found at the back of your SCCS book. While this approach uses the same concepts as the UNIFY plan, it avoids making copies of all the executables; instead, just one custom program, or front end is used to invoke them as needed. This plan takes advantage of the fact that effective IDs can be inherited; see Intro(2) and fork(2). Only the one front-end program needs to be replicated for each separate application.

The front-end approach is clearly workable for UNIFY applications as well, and far preferable in terms of reducing redundant copies of things. The authors of SCCS, while suggesting the approach, did not provide an actual front-end program to use; they assumed each application developer would want it customized and would write one from scratch. It is possible that the lack of a convenient, ready-to-use, easily-customizable front end has been the single biggest reason so many sites have neglected this critical security requirement.

In 1987, James G. Walker of the FJC recognized the value of a front-end approach for UNIFY applications, and wrote a front-end called doappl. doappl is in use in many courts, satisfies the security concern here addressed, and is entirely adequate as far as it goes. invoke was designed to be easier to configure and customize for new applications (no recompile needed) and to be usable for other than just UNIFY database applications. (We also use it, in fact, as an SCCS front end.)

A court currently using doappl with its UNIFY applications may find invoke attractive for the capabilities outlined in the appendix of the secure-rqst memo accompanying this file, and in the accompanying "Trusted Procedures" manual pages. A court running important UNIFY applications without using either doappl or invoke is strongly urged to consider adopting one or the other posthaste; without the required support from the operating system, the purported controls built into the applications cannot be relied on, and the court's information is at risk. Claims by developers to have devised "superior" security mechanisms must be questioned pointedly; the effective-id features are still in UNIX after twenty years because they play an important role that can never be filled by application logic alone. These features need not be used as the only line of defense for an application, but if they are not employed in their proper roles, the other controls are compromised.