Multics Technical Bulletin MTB-515 DM: Security To: Distribution From: T. H. Van Vleck Date: 02/11/81 Subject: New Database Architecture: Security 1 ABSTRACT This memo describes what database security is required for the new database architecture and how we will provide it. The reader is expected to be familiar with basic Multics security, such as rings and ACLs. Comments should be sent to the author: via Multics Mail: Spratt.Multics on either MIT Multics or System M. via US Mail: Lindsey Spratt Honeywell Information Systems, inc. 4 Cambridge Center Cambridge, Massachusetts 02142 via telephone: (HVN) 261-9321, or (617) 492-9321 _________________________________________________________________ Multics project internal working documentation. Not to be reproduced or distributed outside the Multics project without the consent of the author or the author's management. Page i. CONTENTS Page 1 Abstract . . . . . . . . . . . . . . i 2 Current Database Security . . . . . 1 3 Security Functions . . . . . . . . . 1 3.1 Goals for Security . . . . . . 1 3.2 Environment . . . . . . . . . . 1 4 Implementation . . . . . . . . . . . 2 4.1 Basic Strategy . . . . . . . . 2 4.2 Consequences . . . . . . . . . 2 4.3 Details . . . . . . . . . . . . 3 iii Multics Technical Bulletin MTB-515 DM: Security 2 CURRENT DATABASE SECURITY MR9 MRDS provides "Attribute Level Control," which allows the database administrator to specify the accessiblilty of attributes in a database. This restriction of access is accomplished by making database users access their data through a submodel, which may make certain data inaccessible to a particu- lar user. If the user understands how data is stored in vfiles by MRDS, he may make his own software to bypass the submodel; this attempt will succeed or fail depending on the access control lists on the vfiles which make up the database. These ACLs provide some limited control, of a coarser grain than the submodel. Future plans are to provide "Attribute Level Security" by moving all vfiles and programs which touch them into an inner ring, so that MRDS cannot be bypassed. 3 SECURITY FUNCTIONS 3.1 Goals for Security Our basic goal for database security is to provide facilities which will permit any End User Facility to define the type and extent of security appropriate to the application, limited only by the intrinsic properties of Multics itself. It should be possible to provide security for database items which is as reliable and safe as the security now provided for the contents of segments. In order to provide this type of security, all programs which use a database must obey common conventions about the interpretation of access control; there must be no way to bypass the EUF. 3.2 Environment Data may be distributed over multiple systems in the new architecture. DSA provides the conceptual security framework which allows for systems to "handshake" and negotiate security levels. The new architecture will support multiple end user facilities, providing for application-specific interfaces to a user's data. Whether we will support multiple end user interfaces to the same data is still an open question. Page 1. MTB-515 Multics Technical Bulletin DM: Security 4 IMPLEMENTATION 4.1 Basic Strategy The basic implementation strategy will be to use the native mechanism of Multics to provide security whenever possible. This approach is dictated by considerations of efficiency, since the native mechanism is already there and running; and consistency, since providing multiple mechanisms for the same effect is a primary cause of security weakness. The Multics ring mechanism is the basic support for this kind of security. The new database architecture should function in whatever ring it's called in, protecting its data from access by outer rings in the traditional Multics validation-level fashion. The end user facility can then be implemented on multiple levels, like the plans for MRDS. The outer ring of the end user facility is responsible for interfacing to the user, error handling, and so forth: the inner ring will implement the security model it desires, and call upon the database architecture to implement it. This model is exactly like that used for the implementation of mailboxes on top of segments. The ring 1 mail code corre- sponds to the inner-ring part of the end user facility: it implements an extended application-specific security model, and then uses the standard system facilities to provide underlying support. The mailbox code does additional work to simulate AIM and permit ring-1 multi-class objects. If an end user facility were developed which had a similar need, it too could simulate AIM with minimal support from the database architecture. This subject will be taken up if it is ever needed. 4.2 Consequences The current MRDS plan for providing attribute level security is consistent with the new database architecture. Moreover, the MRDS security implementation can proceed without synchronization with the database architecture development. If the database is distributed, it will be distributed in a way provided by the database architecture; the end user facility need not take any cognizance of database distribution (although it may be able to give or take advice). Page 2. Multics Technical Bulletin MTB-515 DM: Security No gates will be provided by the database architecture for users to call. The user will call upon an end user interface, which will invoke the database architecture by whatever means necessary, including a change of execution ring if necessary. The functions of the Ancillary Services portion of the database architecture must obviously operate on the database at the level of the data itself. If a two-level secure end user facility is in use, the user program will be operating at a different level, and must access the AS layer through a gate. Such a gate must be provided by each end user facility, so that the application program can make AS requests in its own terms, directed to the end user facility; these requests will be checked for validity and translated into database architecture terms by the inner-ring portion of the end user facility to prevent interference with the functions of the EUF. 4.3 Details This strategy places several constraints on the database architecture implementation, since it must be prepared to operate in the inner ring environment. Specifically, the architecture must not count on having any I/O streams available, a working directory set, or any condition handlers it didn't establish itself. The inner-ring portion of the EUF must obey these same constraints. In addition, the gate interface from outer to inner must obey the constraints on ring subvertibility which we see in the ring-1 mailbox and message segment implementations: the inner ring code is responsible for ensuring that it does not operate on any data belonging to another subsystem, and that it cannot be tricked into bypassing its own security model by any possible sequence of calls from the outer ring. Page 3.