crypto-secure operating systems - the community for ... · pdf filethe walls of a building:...

Crypto-secure operating systems

by GEORGE I. DAVIDA and BRIAN J. MATI University of Wisconsin-Milwaukee Milwaukee, Wisconsin

ABSTRACT

Enforcement of security policies in most computer systems is carried out by a centralized mechanism, usually the operating system kernel. Such mechanisms strip users of having complete control over access to their property. This paper describes a system that allows the user to determine the security policy to be enforced by independent, secure processes called Guardians. The system provides some of the tools that the Guardians can employ, and the proposed mechanisms provide more flexible security environments for users. In addition, penetration of part of the system does not jeopardize the security of the whole because resources are not owned entirely by one "super user." The mechanisms rely heavily on encryption, which mediates access to objects in the system. The role of the system is reduced to that of a messenger, and although it is possible to deny service, the security of the system is not compromised.

575

From the collection of the Computer History Museum (www.computerhistory.org)

INTRODUCTION

Protection of programs and data in a computer system is the task of the operating system, and security policies evolve over time as multiuser systems change. Because users must share software and devices, including the processor and mass storage, the task of managing the resources is given to the kernel. This leads to the user's total dependence on the operating system for enforcing security policies. The operating system, in turn, depends on some hardware support to protect itself and the user against malicious or accidental damage. However, most of the protection policies are enforced by software. This is because the operating system is responsible for considerably more than protection. It also performs mundane tasks for the user because it is centralized. Centralization has led to the user's dependence on the operating system for a broad range of services. This is best exemplified by the UNIX operating system. 1 An exception to this is the UCLA kernel. 2

SECURITY MODEL

In this paper, we propose to shift responsibility for enforcement of security from the kernel to the user. The operating system will be called on to perform communication tasks between processes, but it will not be responsible for the security of these messages. We also do not wish to rely on the system's reliability to protect against unauthorized access. Failure may result in the denial of service, but not the breach of security. 3

The protection-related hardware of a computer system provides structural support to the operating system. This consists of memory management and user-supervisor partitioning of the instruction repertoire. These mechanisms are insufficient to enforce a fine-grained protection policy. They are similar to the walls of a building: A building's security does not depend on its walls, but on limiting access to individual rooms through such mechanisms as keys, guards, and the like. We propose to provide a similar environment, where the hardware provides the basic underpinnings, and the rest is done by the user-the owner of the objects-using new mechanisms. The environment in which this occurs should be a decentralized system where decisions about security are made locally by the user.

PROPOSED SYSTEM

Our system is a modification of the Berkeley 4.2 UNIX system, which, by virtue of its sophisticated interprocess communication facilities, provides a good basis for developing message-based systems. Our design consists of the following elements: better process protection, especially of any secret

Crypto-Secure Operating Systems 577

keys a process may possess; secure communiction paths between users and processes; independent processes (called Guardians) that act as surrogates for the owners of the system's resources; and a file system that supports these facilities. These elements result in a system where the kernel's role in supporting security is minimized, with a resulting reduction in dependence on kernel reliability. The Guardians are similar to the Monitors described by Graham and Denning.4

, 5

PROCESS PROTECTION

In time-shared systems the processes inhabit the same memory and mechanisms for this must exist while security is maintained. In a single-processor system, one process cannot be interfered with by any other process as it runs. When a process is inactive it is vulnerable both to the reading of sensitive information, such as security keys, and to alterations of its environment. Ideally, there should be hardware mechanisms by which sensitive areas of a process are protected via encryption, when a process is suspended. Because systems that are now available lack such a mechanism, we emulate this feature in our software. When a process is to be swapped out, the period of time that it may be exposed as a result of inactivity is considerably greater than that of a time slice. Therefore the degree of protection afforded to the process in this instance is considerably greater.

USER COMMUNICATION

The role of the system is that of a communication switch that routes messages among the processes and users of the system. The system should not be expected to provide secure communication-that responsibility should rest with the users and the processes. The processes can obtain secure communication in a system using cryptographic protocols implemented with software or hardware. If their local equipment has the capability, the users can do the same. However, if the user lacks this capability, then the system must supply it. Therefore either a user or a process can request that the system cryptographically seal the communication path between them. The seal is provided currently at the interface between the device driver and the device controller via the interrupt-handling routines.

FILE STRUCTURE

A UNIX file system can be viewed at two levels. At the first level, which is more primitive, the file system is flat. It consists of such data structures as a boot block, super blocks, and data


578 National Computer Conference, 1985

blocks. 1 At the second level, the system is tree-structured, with directory files forming the nodes and the regular files and certain special files forming the leaves. All files consist of a single i-node located at a fixed position on a disk, zero or more data blocks, and possibly indirection blocks. The file's i-node contains the protection bits, ownership information, certain time stamps, and pointers to data blocks and indirection blocks. 1

In our system there is an additional protection bit used to denote a secure file, and the following additional fields have been included:

1. Security flag field. The bit flags that comprise this field among other things control, in a secure file, whether the system standard Guardian or some other user-specified Guardian is to be used. Other fields determine whether the first block of the secure file is a secure header block if there is a control file associated with this secure file.

2. Security function control field. This field determines whether a Guardian should be invoked when a particular action occurs.

3. Device numbers. This field provides the major and minor device numbers for the Guardian, assuming the system standard Guardian is not assigned, and the control file if one is in use.

4. Guardian i-number and control file i-number. This field is similar to the device numbers field except that inumbers are stored.

5. Consistency fields. 2 Two of these fields are present. They contain a cryptographic hash of the i-node fields, the indirect blocks, and the data blocks.

6. Reference count. If the file is a Guardian or a control file, this field contains a count of the number of secure files that employ this file.

These additions to the i-nodes result in connections between files other than those of the· logical file system. The connection between a secure file and its Guardian or control file is a direct link. The direct link allows the system to locate the Guardian or control file without performing timeconslltning path traversals. Indeed, a path to the Guardian or control file may no longer eXIst in the 10-giCal file systein,' yet the direct link still exists. The lack of a pathname for the Guardian of control file would result in a lack of direct access to these objects through the logical file system. The crossdevice nature (both logical and physical) of a direct link allows for different physical protection strategies to be used for the Guardian and the control file. The direct link for a file may denote the file itself, allowing a control file to contain its own access permissions or a Guardian to guard itself. This answers the old question, "Who will guard the guards?"

The consistency filed contains an encryption of the fields or the i-node in addition to whatever else (indirection blocks or data blocks, for example) the user may specify. The encryption is by a user-supplied key and the result may be stored in this field, displayed to the user, or both.

GUARDIANS

It is useful to move security-relevant functions out of the kernel. 3 Our system uses processes that achieve the twin ben-

efits of distribution and kernel simplification. The system is based on the concept of a Guardian. A Guardian is a process that acts as a surrogate for the owner of a file system object. This concept is appropriate for multiuser computer systems because the owner of an object usually has partial, if not complete, control over the level of "protection" afforded an object. It is also approprite to keep the function of the operating system kernel to a minimum.6 Our system removes security decisions from the kernel and uses encryption to limit our dependence on the kernel's reliability. The kernel provides services to the Guardians and implements their decisions. It also provides communication paths between processes, but it is not responsible for securing the channel. Secure communication protocols furnish Guardian-toGuardian communication.

Guardians use dynamic profiles of users and fingerprints of processes, kernels, and file system objects to establish the identity of users, processes, systems (kernels), and file system objects. This is an absolutely essential feature. A major advantage of our system is that there is no need for a super user. Each system object, terminal line, and printer spool has a separate owner. In certain cases the owner of a file does not exist and the file can be modified only when the system is off line. Because each Guardian is responsible for those objects entrusted to its care, each enforces exclusive use of secure objects. This solves the problem of interruptability.7 Guardians enforce policies that the owners of system objects deem appropriate by using encrypted tokens, time stamped tickets, or records stored in secured files. When a Guardian is running, system operations are those initiated by its actions, except for interrupt handlers. When a Guardian or any other process is suspended it loses that control.

A Guardian is an independent process in that it is not subject to normal restrictions placed on signals and process termination in a UNIX process. A Guardian is created when a secure file is accessed during the course of a system call when the system converts to serve more than one user. The term accessed in this case refers to the obtaining of an i-node table entry during pathname resolution and subsequent use within that system call.

If access to a secure directory is re-quired during pathname resolution, a Guardian is invoked. The actual file that is the target of the system call (if it is a secure file) also will have its Guardian invoked. If the system call "returns" a file table pointer, the associated file descriptor returned is a socket that connects the calling process to the Guardian (if any access is allowed), and the Guardian has direct access to the secure file via its own file descriptor. Subsequent reads and writes from the calling processes are mediated by the Guardian. Only the Guardian may have a file descriptor that actually refers to a secure file. If, after the pathname search the system call does not return a file descriptor, the caller goes to sleep and the secure file's Guardian runs. The Guardian makes the determination of whether and how the system call should proceed and then exits, returning its decision to the system. At this point the caller wakes up· and the system call proceeds as directed by the Guardian. When a system call is suspended pending the decision of a Guardian an alarm is set before the caller goes to sleep. This alarm will prevent the caller from waiting indefinitely. If the Guardian has not rendered a ver-


dict in the time specified by the caller, the decision is assumed to be complete denial of service. The Guardian is notified and the caller awakes. This mechanism allows users to produce custom-made audit trails via Guardians.

Once a Guardian is created, it runs as the owner of a file. It does not change its identity during the course of execution. With Guardians available there is no need for the standard UNIX set user and set group identification facilities, much less the change user facility. Normally a Guardian is not "exed-able," that is, the execl system call will not work and the calling process will not be overlaid with the Guardian. The only exceptions to this rule occur just prior to the system going into multiuser mode or when the Guardian of a terminal line gives up its post. When users log in, the post is surrendered to give each user a separate Guardian on the line for the remainder of the user's time on the system.

The system provides a number of aids that allow the Guardians to perform their tasks. Guardians must be able to verify their environment, control the execution of their children, and verify the consistency of a process and its text file. The system does not supply any additional process-to-process communiction facilities beyond what is available in UNIX 4.2 BSD. However, sockets have been modified so that a Guardian can support such operations as a seek on a socket (that is, connected to a Guardian that supports it). When the system goes into a multiuser state the "init" process is allowed to execl a number of Guardians. These Guardians protect critical devices that are accessed by means other than the file system (terminal lines via terminal keyboards) or are considered so important that a Guardian should always be on duty.

GUARDIANS IN ACTION

The following are some examples of Guardians in action.

Act 1 A Guardian is camped on a terminal line where no one is currently logged in. If the Guardian will allow a process to read or write to this line which may be connected to a modem or printer, a socket with the standard name of the line will be provided by the Guardian, case A. If communication to the line is not allowed, the configuration is that of case B.

Dtty : Ddd : Gtty,utty : case A

Dtty : Ddd : Gtty, utty case B

Dtty The terminal, Ddd The device driver. Gtty, utty The Guardian of file tty owned by utty, : A communication path.

The Guardian in case A has full responsibility for protecting the line from processes in the system on behalf of the line's owner, who may not exist.

Act 2 The terminal line supports logging in from some remote device, a terminal or another processing unit.

Ua : Dtty : Ddd : Gtty,utty U a The user a.

case A


If the remote device, depicted as a terminal, is going to send or receive critical data, the configuration is first changed to:

Ua: Dtty :e Ddd :e Gtty, utty case B :e A system supported cryptographic communication path.

It is possible the user may provide his own encryption

case C

In case B, the encryption of incoming data is performed by the routine that services a data-received interrupt. The data are transformed just prior to being written to the device register (memory mapped machine).

Act 3 The terminal line Guardian satisfies itself as to the identity of the user (by comparison with a dynamic user profile) and determines that the user should be allowed to use this line. The terminal line Guardian is replaced by a Guardian of the user's choice.

Ua :Dtty :Ddd :Gtty,utty I

Fprof

Fprof The Guardian has opened the file Fprof where Prof represents the contents of the file.

When the terminal line Guardian is created, it is given access to files that contain the profile information used to verify the identify of the user. This profile information is not necessarily independent of environmental factors such as the time of day, which terminal line is involved, or any other condition the Guardian can test. If the Guardian is satisfied, it arranges for the creation of a Guardian for the user. The line Guardian execls the user Guardian (which itself is guarded) and is replaced by it:

Ua :Dtty :Ddd :Gtty,utty~execl FS{Guser,a}a ~ execl The initiation of the system call exec!. FS{Guser,a} The secure file that contains Guser, a , and is owned by a.

If permission to execl F{Guser,a} is granted, the following state is reached:

Ua :Dtty :Ddd :Guser,a

At this point, or at any time after, if the user wishes to receive communications from other processes directly he may instruct the user Guardian to put out a socket:

Ua :Dtty :Ddd :Guser,a :

The Guardian, perhaps after soliciting advice from the user, determines whether it should allow some process to talk to the user and whether it should provide a filter against certain undesirable messages.



Act 4 The user obtains a command interrupter:

Va :Dtty :Ddd :Guser,a

The Guardian forks; its child uses verifiction techniques to check that the shell has not been altered "improperly":

Va :Dtty :Ddd :Guser,a ~ verf F{Pcsh}

If Guser,a is satisfied it performs the fork and execl:

Act 5 The user, having successfully logged in, wishes to alter some especially critical information, for example, his password. A file containing such critical data is a secure file, so the following events ensue:

Va :Dtty :Ddd :e Guser,a : (Pcsh) : P passwd ~ open FS {passwd}pd

Va :Dtty :Ddd :e Guser,a : (Pcsh) : P passwd : G passwd, pd : FS {passwd} pd

Pcsh A process executing csh. (Pcsh) The process Pcsh in a dormant state.

At this point Guser, a uses an ioctl or a message to the user to cryptographically seal as much of the communication channel as possible, given available hardware, and then opens the password file. The two Guardians use cryptographic protocols to set up a secure link between one another.

Va :Dtty :Ddd :e Guser,a : (Pcsh) :E P passwd :E Gpasswd,pd : FS{passwd}Pd

:E A Guardian supported cryptographic communication path.

The file Guardian would write encrypted versions of the password (for example, the password scheme of UNIX, create a checksum for the record, and send this data through to the file). It is always possible that the file Guardian may request additional user verification before updating the file.

Act 6 The user wishes to use a screen editor (called vi) on a secure file:

Va :Dtty :Ddd :Guser,a : (Pcsh) : P csh ~ execl F {P vi}

F{PvJ is not a secure file, so execution proceeds normally (subject to any verification):

Ua :Dtty :Ddd :Guser,a : (Pcsh) : Pvi~open FS{data}b

The Pvi process attempts to open the 'secure file. The file's Guardian is invoked. The new Guardian informs G user, a what Pvi is doing. Guser,a acknowledges, and in so doing assumes responsibility for P v/s actions:

Va :Dtty :Ddd :Guser,a : (Pcsh) : Pvi : Gdata,b :FS{data}b

Pvi makes a temporary copy of FS{data}b under a secure directory, uses cryptographic read, and writes:

Ua :Dtty :Ddd :Guser,a : (Pcsh) : Pvi : Gdata,b : p8{data}b

: F{temp}b

Ua :Dtty :Ddd :Guser,a : (Pcsh) : P vi : F{temp}b

When the data are written back to p8{data}b a similar set of operations is performed. In order for Guser, a to perform its supervisory function the kernel provides it with some control over its descendants. It can have the kernel seek the Guardian's permission prior to performing selected system calls (specifically opens).

Act 7 The user wants to read his mail and will send a reply. The mail program is called and it in turn opens user a's mail file:

Ua :Dtty :Ddd :Guser,a : (Pchs) : P csh ~ execl F{P mail}

Ua :Dtty :Ddd :Guser, a : (P csh) : Pmail~open FS{a's mailfile}a

Replace Ua :Dtty :Ddd by {a ... dd} and let user a's mailman Guardian be invoked. This Guardian verifies user a's identity and then proceeds:

{a ... dd} :Guser,a : (Pcsh) : Pmail : Gmail(a),a : p8{a's mailfile}a

At this point user a can read the mail. Note that if there is something dangerous about the mail that user a is about to read, the line Guardian is there to protect the user. If additional security is required, communication paths can be sealed and the mail message itself can be encrypted. Now user a would like to reply to the message by sending a letter to user b. The mail program opens user b's mail file (not shown) and user b's mailman is invoked. This new Guardian verifies the sender and screens the incoming mail for letter bombs:

{a ... dd} :Guser,a : (Pcsh) :Pmail : Gmail(a),a : FS{a's mailfile}a

: Gmail(b),b : p8{b's mailfile}b

KERNEL MODIFICATIONS

The kernel in this system has been modified to provide support to the Guardians and not to determine policy. The Guardian support facilities include the following:

1. Creation and termination: When a Guardian is created, unlike the case with "normal" UNIX processes, it has no parent. The Guardian does not terminate on externally generated signals, and its initial set of open files is con-


trolled by the data in the i-node of the file it is guarding as well as by the data in its own i-node.

2. Surveillance of children: A Guardian can arrange to "trap" selected system calls of its own descendants (but not those of other Guardians). The Guardian can thereby control the actions of its charges.

3. Verification of caller: The ability to identify the user of a communication line is essential to the proper functioning of a Guardian. Guardians can gain direct access to a terminal line and interact with the user for this purpose.

4. Verification of intended child at call (for execution), verification of a process during execution (frisking), and verification of system identity. The system employs a depository of "process" fingerprints under the control of a phantom user. A phantom user is one that can run or have non-Guardian processes on the system only when the system is in single-user mode. The depository is a secure file or collection of secure files.

HARDWARE SUPPORT

Current hardware configuration consists of a single MC68010 processor and peripherals. Proposed expansion is to include a second· processor with local memory and special-purpose cryptographic hardware. The new processor will allow considerable improvements in performance as well as monitoring functions that are not practical on a single-CPU system. The new processor will implement such cryptographic tools as key sharing.8 The National Bureau of Standards data encryption standard (implemented in special purpose hardware),9 substitution permutation networks,1O database security,S. 11 and arbitration of cryptographic protocols also will be added to the new system.


REMARKS

Most of the elements of security that we have presented can and should be implemented in hardware. In particular, process management must be implemented in hardware to make process suspension and activation safer.

REFERENCES

1. Ritchie, D. M., and K. Thompson. "The UNIX Time-Sharing System." Communications of the ACM, 17, (1974), 7, pp. 365-375.

2. Popek, G., M. Kampe, C. Kline, A. Stoughton, M. Urban, and E. J. Walton. "UCLA Secure UNIX." AFlPS, Proceedings of the National Computer Conference (Vol. 43), 1974, pp. 145-151.

3. Popek, G., and C. Kline. "Issues in Kernel Design." AFIPS, Proceedings of the National Computer Conference (Vol. 47), 1978, pp. 1079-1086.

4. Graham, G. S., and P. J. Denning. "Protection-Principles and Practice." AFIPS, Proceedings of the Spring Joint Computer Conference (Vol. 40), 1972, pp. 417-429.

5. Denning, D. Cryptography and Data Security. Reading, Mass.: AddisonWesley, 1982.

6. Neumann, P. "Computer System Security Evaluation." AFlPS, Proceedings of the National Computer Conference (Vol. 47), 1978, pp. 1087-1095.

7. Ames, S., andJ. G. Keeton-Williams. "Demonstrating Security for Trusted Applications on a Security Kernel Base." IEEE 1982 Symposium on Secu~ rity and Privacy. Silver Spring, Md.: IEEE Computer Society Press, 1982, pp. 145-156. ;

8. Davida, G., R. A. DeMilio, and R. J. Lipton. "Protecting Shared Cryptographic Keys.~' IEEE 1980 Symposium on Security and Privacy. Silver Spring, Md.: iEEE Computer Society Press, 1980, pp. 100-102.

9. "Data Encryption Standard." FIPS Pub. 46, National Bureau of Standards, January 1977.

10. Kam, J., and G. I. Davida. "Structured Design of Substitution-Permutation Encryption Networks." IEEE Transactions on Computers, 28 (1979), 10, pp. 747-753.

11. Davida, G. I., D. Wells, and J. Kam. "A Database Encryption System with Subkeys." ACM Transactions on Database Systems, 16 (1981), 2, pp. 133-140.


Panel Abstracts 583

Panel: Trends in computer systems technology

Chair: JOHN L. BERG, Sperry Corporation, St. Paul, Minnesota

Members: SHELDON A. BORKIN, IBM Cambridge Scientific Center, Cambridge, Massachusetts ALFRED W. DiMARZIO, General Electric, Bridgeport, Connecticut JOHN HEFNER, National Bureau of Standards, Washington, D.C. EUGENE LOWENTHAL, Microelectronics and Computer Technology Corp., Austin,

Texas REID SMITH, Schlumberger-Doll Research, Ridgefield, Connecticut

Can the innovations in computer technology over the next 10 years be predicted on the basis of the measured trends of the last 10 years? Some analysts say no, citing microcomputers/workstations, database/information resource management, LANs, artificial intelligence applications, and user interfaces as technologies for which extrapolations are not easily made. A panel of industry analysts discusses this issue.

Panel: Visual languages

Chair: S. K. CHANG, Illinois Institute of Technology, Chicago, Illinois

Members: ADARSH ARORA, Gould Research Center, Rolling Meadows, Illinois ROBERT B. GRAFTON, Office of Naval Research, Arlington, Virginia MARGARET A. KORFHAGE, Trammel Crow Company, Dallas, Texas MOSHE M. ZLOOF, M. M. Zloof, Inc., Dobbs Ferry, New York

This session focuses on the theme of visuallangauges. Topics to be considered by the panelists include visual programming, form-oriented programming visual interfaces for information systems, and the design of visual and icon languages. Visual languages will grow in popularity because of their emphasis on high information density, man-machine communication. The panel also considers the future of such languages.



Panel: Software engineering directives

Chair: MARIO BARBACCI, Carnegie-Mellon University, Pittsburgh, Pennsylvania Members: JOSEPH BATZ, The Pentagon, Washington, D.C. NICO HABERMAN, Carnegie-Mellon University, Pittsburgh, Pennsylvania W. MacDONALD MURRAY, General Dynamics, St. Louis, Missouri

The Software Engineering Institute (SEI) is being established by Carnegie-Mellon University under the sponsorship of the Department of Defense to address the problems of software development. The overall objective of SEI is to increase the quality and decrease the cost of software by improving the software development process. As part of its mission, SEI will endeavor to expedite the transition of new software development technology from research into actual practice.

In this panel session, members of SEI and representatives from government and industry describe the goals of the institute, its organization, and the initial set of projects. Further discussion focuses on directions for software engineering research as envisioned by SEI.

Panel: Can we make programming tearps succeed?

Chair: ANNELIESE von MAYRHAUSER, Illinois Institute of Technology, Chicago, Illinois Members: J. DANIEL COUGER, University of Colorado, Colorado Springs, Colorado NICHOLAS MARSELOS, AT&T Network Systems, Lisle, Illinois CARMA L. McCLURE, McClure Associates, Chicago, Illinois

Almost since the beginning of programming, the problems programmers were involved with were complex enough that they had to organize and work in groups. Formally defined programming teams promised a more structured form of organization and greater project success. The high expectations these concepts generated were shattered when problems with software development persisted in spite of these new structures and technologically knowledgeable team members.

This panel discusses experiences with team concepts, analyzes them, and develops reasons why the application of team concepts may have failed, as well as suggestions on how to prevent such failure. In particular, motivational theory, task design, and team-building strategies are discussed.


Panel: Decision support systems

Chair: ROBERT W. BLANNING, Vanderbilt University, Nashville, Tennessee Members: GARY W. DICKSON, University of Minnesota, Minneapolis, Minnesota JOHN C. HENDERSON, Massachusetts Institute of Technology, Cambridge,

Massachusetts MILES H. KENNEDY, Case Western Reserve University, Cleveland, Ohio BENN R. KONSYNSKI, University of Arizona, Tucson, Arizona ANDREW B. WHINSTON, Purdue University, West Lafayette, Indiana

Panel Abstracts 585

This panel discussion focuses on a broad range of topics concerning DSS. Included in the discussion will be

-The state of the art of DSS, including applications and organizational and technological issues affecting DSS development

-Current and projected research issues in DSS, including the potential impact on end users

-The impact of forthcoming technologies-such as more powerful microcomputers and executive workstations, inexpensive AI (LISP and PROLOG) processors, and improved data communication services-on the future of DSS

Panel: Information system support for engineering applications

Chair: PETER DADAM, IBM Heidelberg Science Center, Heidelberg, West Germany

Members: ALEX BUCHMANN, National University of Mexico, Mexico City, Mexico KLAUS DITTRICH, University of Karlsruhe, Karlsruhe, West Germany RANDY JOHNSON, Boeing Computer Service, Seattle, Washington STANLEY SU, University of Florida, Gainesville, Florida

The use of the computer to aid engineering design such as CAD/CAM and robotics has flourished in recent years. However, such design applications have been handled as separate processes. Data generated from one application are not easily communicable to other processes. With the right enviornment, this need not be the case. In particular, integrated information systems supporting the entire process, from design to manufacturing to marketing, can be developed. Naturally, techniques and knowledge developed from database management systems can be of use.

This panel addresses the problem of defining an information system to support engineering applications. The state of the art in this area is briefly discussed. Further, the panel considers the problems and requirements of such a system as well as some of the proposed solutions.



Panel: Software engineering standardstoday and tomorrow

Chair: LAUREL V. KALEDA, IBM, San Jose, California Members: H. JACK BARNARD, AT&T Information Systems, Denver, Colorado DAVID CARGO, Honeywell Inc., Minneapolis, Minnesota JOHN HORCH, Teledyne Brown Engineering, Huntsville, Alabama PHILIP C. MARRIOTT, NCR Corporation, Dayton, Ohio GEORGE D. TICE, JR., Tektronix, Inc., Wilsonville, Oregon

Current software engineering standards activities are described, especially those sponsored by the IEEE Computer Society. Discussion by the panelists focuses on such topics as

-Standards, guides, and practices under development and already approved -The development process used for IEEE-sponsored standards -The interrelationships of the IEEE Standards/Practices/Guides and other

software engineering standards, such as Mil-S-S2779A SQA program requirements

-Future directions of these efforts


NETWORKING HARVEY FREEMAN, Track Chair

Architecture Technology Corporation Minnetonka, Minnesota


crypto-secure operating systems - the community for ... · pdf filethe walls of a building:...

Documents