Two Secure File Servers
Fred Cohen* and Steve Bruhns**
*University of Cinncinatti
**Lehigh University

Keywords: Secrecy, Integrity, Network File Servers, Secure Networks, Trusted Systems

Abstract

In this paper, we describe the design and implementation of a two secure file servers which allow a trusted computer network to be built from untrusted computing bases. We begin with a brief review of recent results in the use of partial orderings for protection and administration of information networks, and introduce limited functionality TCB file servers as a means for allowing restricted information flow. We show the means by which such a server may be made provably secure, consider the practicality of implementation, and describe two prototype implementations for personal computers. We then summarize results and point out possible extensions of this work.

1 - Introduction

Protection of information in modern information networks depends primarily on the ability to control the flow of information [1,4,5,6,7,10,11]. The partial ordering is the most general mathematical structure required to accurately model the information flow behavior of a general purpose transitive information network [1]. In this paper, we introduce the concept of a limited functionality TCB file server for a POset network, describe the first prototype implementations, and report on their use in an experimental environment.

Unless otherwise stated, we assume that general purpose computer systems are used, and thus that transitivity holds for information flow [5]. We assume that there is no real difference from the standpoint of an information network between subjects and objects [1], and study the effects of information flow disregarding this distinction. We call the undistinguished subject/object an "information domain", abbreviated "domain". We view the effects of a human subject having access to multiple domains as a collusion between domains, and thus keep the mathematical analysis simple and general. The information flow relation "f" between domains from a set of domains "S" forms a partially ordered set (POset) and is specified in [1] as: 

(S,{f}): for all a,b,c in S,
        [(a f a)                                ;reflexive
        and (a f b) and (b f c) => (a f c)      ;transitive
        and (a f b) and (b f a) => (a = b)]     ;antisymetric

The effective POset under transitivity is formed by applying transitivity to information flow, and is easily displayed in matrix form. This shows information reachability immediately without undue complexity to the observer. We call the effective POset under transitivity a "Flow Control POset" (FCP). The corruptive effects of domain collusion can be efficiently determined by ORing rows of any set of colluding domains to find their effective joint flow. Similarly, the information accessible to a set of colluding domains can be derived by ORing their respective columns.

The POset in this context may be thought of as a classification scheme, just as the Bell-LaPadula security levels [6] and the Biba integrity levels [7] are classification schemes. We may have distinct yet equivalent domains in an actual system, but the distinction isn't "real" from the information flow standpoint. We must be aware of these equivalencies in order to determine actual information effects.

The POset model is used to design flow controls in a given application. That is, the application drives the partitioning of domains and the need to flow information between domains. Once information flows for an application are established, individuals are allowed to effect or observe information in domains as required for their work [14].

If we assume that a network is properly implemented and that external attackers are successfully thwarted by common techniques, we are left with the effects of internal errors and abuse. Analysis is based on intentional attacks by internal groups of individuals, but the method works equally well in the analysis of accidental leaks and corruption, and external attacks can be modeled as internal attacks with probabilities adjusted by the probability of successfully forging associated identifications and authentications. We use an extension of standard risk analysis techniques [2] that reduces the complexity of analysis by taking advantage of the restricted interdependence of domains under a partial ordering [1,4,11,14].

Since individuals in an information network may access multiple domains, it is convenient to consider individuals as collusions of domains. The maximum effect of an individual is the combined transitive effects of all domains which that individual can effect; while the maximum dissemination by an individual is the combined transitive effects of domains affecting the individual. To consider groups of individuals who might collude to launch an attack, we analyze them in the same manner as a single individual with their combined access [1,4,11,14].

The connection of trusted computing bases (TCBs) and untrusted computing bases (UCBs) [10] to form a network which enforces POset properties is possible, both in communications environments with trusted paths, and those with untrusted paths [4,11]. Simple design rules exist for the connectivity of systems, and these rules are extended transitively to networks[1,4,11].

In an untrusted computing base, we cannot trust the system to prevent flow between domains, and therefore, from the standpoint of systems which flow information to or from a UCB, the UCB must be treated as a single domain. In an environment with trusted communications paths, two UCBs can communicate if and only if (iff) they are the same domain. If we have a means for unidirectional communication, we can permit UCBa to communicate to UCBb iff (a f b). In such an environment, we can form a POset TCB by using the physical properties of unidirectional connectivity to protect information from illicit flow, and the physical structure of the network to form the POset [1,4,15].

In the case of TCBs communicating in a trusted communications environment, we may permit any domain (A) in TCB1 to communicate to any domain (B) in TCB2 iff (AfB). Again, this requires unidirectional communication. If bidirectional communication is used, we allow connections of the form (AfB) iff A=B since, by antisymetry [(AfB)and(BfA)=>(a=b)]. For any UCB (X), if X is a single domain (d) then x can be used for passing information, so long as for all domains a that flow to X, (afd) AND for all domains c that X flows to, (dfc).

Because the POset has the transitivity property, a network comprised of TCBs and UCBs connected by the above rules will maintain the flow control properties of the network's POset. In the case of a violation of the POset policy within a TCB, the damage to the entire network can be no worse than making all domains in that TCB equivalent since for all domains (x,y) in the TCB, [(xfy)and(yfx)=>(x=y)].

Any violation in a UCB effects only that UCB's domain. We may straight forwardly use collusion analysis to determine the effects of flow violations and time transitivity. In fact, the use of a computer network to implement an information network in this case is completely transparent, and all analysis that is operative in the information network applies directly to the computer network. Thus because of transitivity, we may connect computer networks without loss of assurance as long as we follow the connection rules.

In a network with untrusted communications paths, we may encrypt and authenticate connections of the same form as those in the trusted communications case, and we will still have an appropriately connected network with the transitive flow protection properties stated above. Care must be taken to assure that cryptosystems offer sufficient protection for the application at hand and that communications protocols do not introduce covert channels. The sufficiency of cryptosystems is application dependent, and has been covered in previous works [10,11,12]. A scheme with arbitrary delay on end to end confirmations and a constant portion of system time and space dedicated to the network functions would tend to reduce covert channels, but their complete elimination is impractical in almost all instances.

2 - Secure File Servers in Networks

File servers have been used for several years as a method of allowing local area networks (LANs) with many processors to share a common file structure. In many such networks, the file server is also used as a mail server, an interface to external networks, and a machine from which the network is managed. As we have just seen, TCBs can be used to connect UCBs so as to form a trusted computer network (TCN). If we combine the purposes of a network file server and a TCB to form a secure network, we have the concept for a secure network file server. The major advantages of a secure file server over other forms of TCBs for forming secure networks are:

The major advantages of limited functionality in a TCB are that it is much easier to design, implement, prove correct, assure, manage, maintain, and operate. In typical general purpose machines, there are very large numbers of possible system states, asynchronous activities often take place, resources are dynamically allocated, multiple processes may be active and attempting to communicate at any given moment, and the complexity of the operating system far exceeds that of most programs running under it. The design of such a system often takes many man years, implementation flaws are usually numerous, updates happen on an ongoing basis, there are many changing system parameters that dictate performance and other characteristics, and many oportunities exist for hostile exploitation.

A simple limited functionality file server can be implemented by a single individual in a matter of hours, has only a very small number of states, needn't have asynchronous behavior, need only use a single process, needn't protect its resources against exploitation except through one simple user interface, and needn't have a large number of parameters or other features. It is very straight forward to verify the entire design and implemntation, and there needn't be a great deal of effort to maintain or update it. Only file server activities may operate on such a system, and as such it is not useful for anything but a file server and communications device.

3 - A Simple Secure Network File Server

The 'C2' trusted file server is designed to allow users with very few resources the ability to maintain a relatively high degree of protection over critical information. C2 is implemented for a standard personal computer (i.e. IBM-PC) with a built in hard disk, RS232 interface, and battery backup system clock. The implementation assures the protection of information by captively operating the PC. C2 allows users to access information through the RS232 interface, and as such can be attached to any number of other PCs within a trusted communications environment. The conceptual design of this system appears to be sufficient for implementation of an A1 TCB [10], but the implementation described herein does not provide this level of assurance.

The basic philosophy of C2 is the protection of information by providing a limited functionality TCB file server that can be networked to single level UCBs over trusted communications paths. A trusted network can thus be implemented by connecting single level UCBs to a multilevel TCB which controls all information flow between UCBs. This implementation serves to demonstrate the manner in which such systems can be designed and implemented at very low cost in a very short time.

C2 is based on a mandatory access control (MAC) policy that allows the system administrator to specify pairs of controlling and controlled users. The controlling user is granted the right to grant discretionary access control (DAC) rights to the controlled user. The DAC rights include 'read', 'write', 'append', and 'ownership', where ownership is the right to grant DAC rights. By acting as both a user and an administrator, the administrator can implement a POset and thus any other desired flow control restrictions. An example of how the MAC and DAC can be combined to enforce a POset flow control policy is the creation of users that act as flow intermediaries between other users. In a system with users X and Z unable to communicate, we can introduce a user Y such that X can grant rights to Y and Y can grant rights to Z. If X grants Y ownership rights to a file X_F, then Y can grant Z read access to X_F, and thus allow one directional flow. A single user of this sort can thus provide access control

We note that as a philosophical matter, the entire system in its present form is monotonic in its granting of rights and creation of information. By this we mean that there is no revocation of rights allowed by the system, and no deletion of files, even though the information contained within them may be overwritten by authorized individuals. It turns out that without revocation, the problem of assessing the transitive effects of information corruption and leaks is quite straight forward, and at least in this sense, there is an advantage in irrevocable actions.

The philosophy is translated into design by implementing a limited set of primitives that perform each of the desired system functions. Because the system is of limited functionality, all permitted functions can be explicitly specified, and the testing procedure can be designed to do exhaustive tests of the control mechanisms. Because the system is monotonic in its control function, the time effects of flow control can be easily computed at any given instant of time, and revocation problems can be entirely ignored.

Security Policy:

All users are given user IDs and passwords by the system administrator through the c2a administrative program. Users must present their ID and password to the system before any actions are permitted. Objects (data files only) are named as the user ID followed by '_' followed by a user determined name, and thus each file is marked with the user ID, and the same file name cannot be created by two different users.

The enforcement mechanism consists of a MAC access control list that only the administrator can append to. The MAC grants users the right to grant DAC rights to other users. The DAC access control list allows users with specific MAC rights to grant specific other users, read, write, or ownership authorization. Groups of individuals may be granted rights through successively granting rights to each member.

Both the MAC and DAC mechanisms grant no rights by default, so that explicit action is required in order to grant rights. All users are denied access to files unless explicitly granted access. Access permission to an object by users not already possessing access can only be assigned by users authorized to grant that access under both the MAC and DAC mechanisms.

Each file has an extent determined by the amount of information written into it by authorized users. Both writing and reading are sequential operations beginning at the beginning of the file. Read is terminated by the end of file marker, while write puts an end of file marker at the end of the written data. Furthermore, a file cannot be read until it is written. The object reuse problem wherein spurious data might remain on disk and be read by the allocation of that disk area without data destruction is thus eliminated.

Accountability:

The TCB requires all users to identify themselves before performing any other actions. Furthermore, the TCB requires that each user enter a user dependent password before being granted access. Authentication data is not accessible by any user. The TCB enforces individual accountability by uniquely identifying every user, auditing each action requested by each individual, and reporting on the success or failure of every action.

The TCB creates, maintains, and protects from modification or other unauthorized access or destruction, an audit trail of every action taken by every user of the system including the administrator. Only the system administrator has access to audit information. There is only one terminal and one console for this system, and the console only runs administrative programs, while the RS232 port only services user requests. The system administrator can selectively audit the activities of each user ID or each audit message. The system maintains a time stamp with every audit entry showing the year, month, day, hour, minute, and second of the audited action, each being represented by a two digit number in the aforementioned order.

Assurance:

The TCB maintains the entire computer as a domain for its own execution, and is thus protected from all external interference except for that caused by input from its RS232 user interface or physical attack. The TCB isolates the RS232 interface by completely controlling all IO to and from that interface.

System integrity is maintained by a software integrity maintenance mechanism which selectively performs and verifies cryptographic checksums on itself and all other TCB programs and files [12]. The system hardware performs a firmware self test upon initialization.

4 - Secure Data Base: Evaluation and Policy

The "Secure Data Base" (SDB) was developed in Turbo Pascal on a IBM-PC compatible microcomputer. The basic goal in the writing of SDB was to provide a capability based secure file server with limited capabilities and maximum protection. Each user has their own domain in which files can be read, written, and deleted. Domains are maintained by providing each with a DOS directory. In order to gain access to a domain, the user must enter the domain name and a corresponding password.

The most important part of the SDB protection system is the use of tokens. Tokens in SDB are similar to tokens in subways in that you need a token to reach your destination. More specifically, there is a set of tokens 'T={t1,t2,...}' that each grant a subset of the set of all rights 'R={r1,r2,...}' over a subset of the set of valid files 'F={f1,f2,...}'. When a particular token (e.g. t1) is entered, the right(s) (e.g. read f1, write f2) associated with that token are granted.

SDB performs actions associated with each right, so when multiple rights are granted by a single token, SDB must prompt the user for the particular instance to be acted upon. If the user in this case enters f1, the information stored in that file will be displayed, while the entry of f2 will cause SDB to input a new version of f2 to replace the old one. If the token entered is not a n element of T, the system will prompt for a new token after a finite delay. Similarly, if there are a number of possible rights associated with a token t, and the user specifies an invalid one, SDB will prompt for a new token after a finite delay.

The protection provided by SDB is a function of the degree to which the space of all possible inputs is filled by the space of valid inputs, and the difficulty associated with differentiating the subspace of valid inputs. In SDB, each user is assigned three tokens by the operator when the domain is created. The 'write' token either overwrites a current file or creates a new one depending on whether the file already exists. The 'read' token outputs a file. The 'delete' token deletes a file after asking the user for confirmation. Each of these tokens can be up to 72 characters long. Thus, the maximum protection that could be provided by SDB in this implementation would be to reduce the likelihood of an attacker gaining any access right to a particular user's files to 3 in 26**72 (or about 1 in 10**102).

Every time a user enters a token, whether it is valid or not, a record of it is kept in a token log. The operator of the system has the ability to read this log to track usage, file allocation, and attempted break-ins. The operator of SDB is also the system administrator. While each user's domain is a subdirectory on the disk, the operator works from the root directory, and can read, write, and delete files, perform audits, list all domains and tokens for each user, and create or delete domains. The operator cannot directly access user files.

6 - Summary, Conclusions, and Further Work

Two secure network file servers have been prototyped, and their designs explained. Both servers are capable of being implemented as provably secure systems, but further work will be required in order to attain this level of assurance. The designs are quite simple and straight forward, primarily because they are limited functionality systems. They both provide the basic functionality required to implement a provably secure POset network, and it is likely that provably secure implementations of these two designs will soon follow.

The implementation of these secure file servers demonstrates a new approach to the implementation of secure systems, in that limited functionality is exploited to provide an inexpensive method for forming a provably secure information network using UCBs for processing, and a TCB for flow control and communications.

The implementation of provably correct versions of these systems is important for their widespread use. Enhanced performance, reliability, and administrative tools will greatly aide in the eventual utility of these systems.

References:

[1] F. Cohen, "Protection and Administration of Information Networks Under Partial Orderings", Computers and Security, V6#2, April 1987

[2] T. Saltmarsh, P. Browne, "Data Processing - Risk Assessment", Advances in Computer Security Management, V2, 1983.

[3] D. Denning, "Cryptography and Data Security", P279-280, Addison Wesley, 1982

[4] F. Cohen, "Design and Administration of Distributed and Hierarchical Information Networks Under Partial Orderings", Computers and Security, V6#3, July 1987.

[5] F. Cohen, "Computer Viruses", Dissertation at the University of Southern California, 1986.

[6] D. Bell and L. LaPadula, "Secure Computer Systems: Mathematical Foundations and Model", The Mitre Corp. 1973

[7] K. Biba, "Integrity Considerations for Secure Computer Systems", USAF Electronic Systems Division, 1977

[8] E. Moore and C. Shannon, "Reliable Circuits Using Less Reliable Relays", J. Franklin Institute, #262 pp191-208, Sept. 1956.

[9] J. von Neumann, "Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components", Automata Studies, C. Shannon, editor Princeton University Press, pp43-98, 1956.

[10] M. Klein, "Department of Defense Trusted Computer System Evaluation Criterion", 1983, Department of Defense, Ft. George G. Meade, Md.

[11] F. Cohen, "A Secure Computer Network Design", Computers and Security, V5#3, 1985

[12] R. Rivest, A. Shamir, L. Adleman, "A Method for Obtaining Digital Signatures and Public Key Cryptosystems", CACM V21#2 (Feb. 1978) PP120-126

[13] J. Dennis and E. VanHorn, "Programming Semantics for Multiprogrammed Computations", CACM V9#3 (Mar. 1966) pp143-155

[14] F. Cohen, "Design and Administration of an Information Network Under a Partial Ordering - A Case Study", Computers and Security, Aug, 1987, 7 pages (in press)

[15] F. Cohen, "Designing Provably Correct Information Networks with Digital Diodes", Computers and Security, (in referee)

[16] F. Cohen, "A Cryptographic Checksum for Integrity Protection", Computers and Security, (in press).