A High Assurance MLS File Server - Semantic Scholar

A High Assurance MLS File Server Jeffrey Choi Robinson and Jim Alves-Foss Center for Secure and Dependable Systems University of Idaho Moscow, ID 83844

[jeffreyr,jimaf]@csds.uidaho.edu ABSTRACT In this paper, we present the design of a high assurance file server model developed to operate within the Multiple Independent Levels of Security framework. The file server model is a multilevel application that utilizes separation to mediate information flow by adhering to a security policy formulated from a modified version of the Bell and LaPadula Model and the GWVr2 policy, which is a separation kernel based policy developed for high assurance architectures. This paper focuses on the design aspects of the file server model and the underlying architecture. The purpose of this file server design is to develop a formal model to meet the formal methods requirement of Common Criteria, which is a system design and specification guideline for high assurance systems. The model is also an example application for the Multiple Independent Levels of Security architecture.

1. INTRODUCTION In high assurance computing environments, failures, accidents and faults can have catastrophic results. For computing systems operating in critical infrastructures, it is essential that they function in an expected and predictable manner without irregular side effects. The application of formal methods in software and system development can be used to produce formally verifiable systems [13]. These systems provide the level of assurance needed to operate in high assurance computing environments. In this paper, we present the design of a multi-level secure (MLS) file server, which is referred to as MLSFS throughout this document, designed to operate in the high assurance architecture known as Multiple Independent Levels of Security (MILS). The design was developed by extending previous work in MLS file servers, file systems, and relational databases. It serves as a starting point for the development and implementation of a formal model created to satisfy Common Criteria requirements. The research does not explicitly address storage security since the high assurance architecture MILS acts as a trusted computing base. However, in Section 5 we address how our system can tie into such storage security systems as described by Riedel et al. [22]. There are cases in which storage security would be required in addition to framework we propose. The framework develops a MLS solution that can utilize single-level secure storage solutions, allowing for reduced development costs. The full exploration of this concept is left as future work. Common Criteria [8] is the current international information technology standard for high assurance security certification. Common Criteria provides developers with a set of requirements for security dealing with functionality and assurance. Common Criteria is based upon original work from the United States Trusted Computer Security Evaluation Criteria [26], European Information Technology Security Evaluation Criteria [7] and Canadian Trusted Computer Product Evaluation Criteria [6]. In 1996, the first version of Common Criteria was created in a joint

international effort by United States, Canada and several European countries. Common Criteria offers seven different evaluation assurance levels (EAL) with the highest level being the most rigorous. The EAL requirements are summarized in Figure 1 as presented by Bishop [5]. At EAL1 the system in question need only be functionally tested to verify that the application or system does what it is intended to do. As the levels progress, more rigorous requirements are taken into account. Beginning with EAL5, a form of formal methods is required, and the highest level EAL7 requires a rigorous application of formal methods. In addition, an EAL7 certified system requires a well-specified system by means of a formal specification that clearly maps to the design and implementation. As previously mentioned, the MLSFS design discussed in this paper is a starting point for a larger body of work and it serves as an example to show how the formal methods requirement for Common Criteria EAL7 can be met. The larger body of work uses the design to develop a formal specification and formal model with the formal methods tool ACL2 [21]. In addition to meeting Common Criteria EAL5+ formal methods requirements, the model is an example application for the Multiple Independent Levels of Security (MILS) architecture. The paper’s remaining sections are organized as follows. Section 2 provides an overview of the high assurance architecture referred to as MILS. Section 3 surveys pertinent research to multi-level file systems and discusses their relevance to our design. Section 4 introduces the model, specifically covering the formal security policy, data structures and the file server operations. Section 5 contains concluding thoughts and discussion about the direction where the research is headed.

2. MILS The Multiple Independent Levels of Security (MILS) is a high assurance architecture designed to meet the requirements of Common Criteria [2][14]. MILS provides a dependable, reliable, secure and safe architecture for high assurance applications that are non-bypassable, evaluatable, always invoked and tamperproof [2][14]. The development of MILS is a joint research effort by academia, industry and government. A MILS system consists of three general layers, depicted in EAL1 – functionally tested EAL2 – structurally tested EAL3 – methodically tested and checked EAL4 – methodically designed, tested and reviewed EAL5 – semi-formally designed and tested EAL6 – semi-formally verified design and tested EAL7 – formally verified design and tested Figure 1. Summarized EAL requirements

Partitions Processes

2

1

MILS Middleware

MILS Middleware

MILS Middleware

S

4

Guard

MMR

TS

3

Separation Kernel Separation Kernel

Figure 2. Three layers of the MILS architecture. Figure 2, that are the separation kernel, middleware services and applications. This layered approach is extended from Rushby’s original work [23]. Separation kernels exist at the lowest layer and isolate processes and their resources in separate execution spaces called partitions. The separation kernel’s primary role is to enforce data separation, information flow, sanitation and damage limitation [2][14]. It achieves its task by regulating inter-partition communication. The separation kernel ensures a partition’s execution does not interfere with another’s unless permitted. The next layer is the middleware services; they provide secure interobject message flow by labeling and filtering messages and enforcing information flow controls. Middleware services consist of enforcement mechanisms that create authorized communication between applications. The MILS message router (MMR) is a middleware service that works in tandem with the separation kernel to enforce information flow policies [2][14]. Other middleware services may include guard mechanisms that downgrade messages or execute protocol-specific policies. In addition, a network-based MILS system can also exist, where communication between hosts is controlled by middleware. At the topmost layer are applications that reside in partitions. The applications consist of trusted and untrusted software systems. MILS relies on multiple application layers that may have independent security policies [2][14][27]. The approach of separating processes allows for smaller components that are independently verifiable and reusable, thus reducing the amount of work needed for proofs and allowing MILS to satisfy the requirements for EAL5+ certification. An example process of a single MILS system, Figure 3, consists of the secret (S) partition sending a message to the top secret (TS) partition. The process starts with (1) S generating the message and putting it on an outgoing port that the MMR intercepts, (2) the MMR forwards the message to a content guard and (3) the guard verifies the outgoing message does not violate the information flow policy and returns it to the MMR and (4) the MMR forwards TS the message. The converse example of a reverse flow of information presents an entirely different chain of events, which is not displayed in Figure 3. (1) TS puts a message with TS data on an outgoing port for S, (2) the MMR intercepts the message and sends it to the content guard, (3) the guard analyzes the message and determines TS is sending information rated above S’s level and (4) the MMR denies it. The MLSFS is designed to operate as a MILS application, where it benefits from many of MILS’s features. Specifically, the concept of separation can be applied to show non-interference on the file server operations. The MILS separation kernel allows for file systems to exist on logically and/or physically separated

Figure 3. Information flow example single MILS system: S sends TS a message. partitions that may be local and remote systems. This, in turn, permits a distributed file system. The ability to have secure local and remote file systems is a key advantage of using the MILS architecture as the backbone. All internal (local) and external (network) communication are abstracted and guaranteed to be as secure as the MILS architecture in respect to communication, authentication and integrity.

3. MULTI-LEVEL FILE SYSTEMS Williams and Dinolt [28] presented a formal, mathematical model of a trusted file server (TFS) for a MLS distrusted computing system. The authors state the TFS is intended to be a long-term file store, where data may be stored for days, weeks, months and/or years. The system represents file objects by a unique name, number of blocks and a security attribute descriptor (SAD). The SAD denotes an object’s security credentials. The system allows user callable operations to create a file, delete a file, write a block, read a block, set size of a file, get status of a file and get label of a file. The TFS also includes one input and two output buffers that are used to track incoming, response and audit messages. The history buffers are important to the model’s verification. The authors assert that as long as the system security policy in relation to the input and output histories of the system is met for all time, the system is secure. The authors refer to an exact match security policy, where the SAD in a request message must match that of the requestor, as well as the file in question. An external, trusted component in the system is used to mediate the adherence to the exact match security policy. A drawback of this system is a high dependence on an external environment. While the MLSFS has similar dependencies in that it requires the MILS architecture as its base platform, MILS is a more extensible platform than the architecture presented by Williams and Dinolt. In addition, there is no discussion how the objects are stored in the file system, or how the user interacts with the file system in terms of viewing the directory structure or the contents of a directory. As it stands, the TFS uses a flat file system with no directories, which is clearly a limitation. Furthermore, the TFS is intended as a long-term file store, which restricts it usefulness. The MLSFS is intended as a general purpose file store and addresses the TFS’s limitations. However, the notion of abstracting the enforcement of security policies to an external source is of interest. It implies that we can treat the MLSFS as a black box system and ensure security policies the system was not

The virtual multi-level file system (VMLFS) incorporated into Irvine’s file system is of interest. The VMLFS utilizes the GARNETS file system and separates data by its security credentials. When a SLS subject interacts with the system, their interpretation is created on a per access class (PAC) basis. PAC links contain views of the system a given user is permitted to interact with. The system uses aliases, which provide multiple connections to an object that can only be erased when it has no active references, and symbolic links, which provide transparent links to objects. Both aliases and symbolic links provide the VMLFS with the ability to generate views of the system on a PAC basis. The VMLFS concept itself was developed to allow for existing GARNETS file systems to be manipulated for use in a MLS fashion. We extend the notion and integrate separation and noninterference to provide the MLSFS system with a method to handle multiple SLS file systems and interpret them into a MLS entity in a dynamic fashion. McNamee et al. [20] investigated cross-domain services by developing multi-level file system services that utilize underlying MILS components and concepts. The architecture uses isolated SLS networks, e.g. a high level network contains all high level users and a low level network contains all low level. The research provides a solution to an ongoing issue, if a high level user needs access to low level data, the entire low level file system storage must be available to the high level network. Since the networks are physically separated, there is not an easy solution. McNamee et al. present a solution using MILS components and a trusted service engine that mediates read and write requests to provide a multi-level file store. The essential component of the system is the block access controller (BAC). The BAC is the specific component in the architecture that provides cross-domain services. In accordance to the Bell-LaPadula information security policy and as exactly described by McNamee et al., the BAC has the following inherent properties: 1.

Mediate all disk block access

2.

Connect SLS disks and partitions

3.

Write blocks to the same level

4.

Read blocks from the same or lower levels.

File Server

Unclassified

Confidential

Secret

Irvine [15] conducted research that investigated the development of a multi-level file system as a component in a high assurance operating system GARNETS. The motivation of the research was to expand the file system capabilities of the GARNETS system to provide a multi-level file store with mandatory and discretionary access controls. Irvine’s file system, compared to Williams and Dinolt [28], is more complex in design. It includes a directory structure, object name aliasing and linking, discretionary and mandatory access control and a virtual file system that allows users with different security credentials to have different interpretations of and interactions with the system. Essentially, Irvine provides a framework for using single-level secure (SLS) file systems and interpreting those file systems in such a way that users believe they are interacting with a MLS file system. This concept is very important to the development of the MLSFS.

Top Secret

originally intended to support using external enforcement mechanisms. This concept is particular of interest if we want to add MILS downgraders or upgraders to the system.

Figure 4. MLSFS in the MILS architecture. All of these properties are similar to the MLSFS design. (1) is important simply because mediation and control of the incoming requests and outgoing traffic is vital to preserving confidentiality. (2) introduces the notion of physical separation, which the MLSFS is based upon. However, the MLSFS does not consider physically separate networks isolated by security levels, but relies on high assurance MILS components such as the separation kernel and the MMR to control the flow of information. (3) and (4) follow an adapted version of the Bell and LaPadula Model (there is no write-up, only write-across—write access is restricted to same level), which is also used in our design. In addition to research in multi-level file systems, previous work in multi-level relational (MLR) databases has played a significant contribution to the development of the MLSFS. Denning et al. [9] presented a formal model and security policy of a secure MLR database system called the SeaView model. The model considers the interaction of database views, instances, snapshots and their relation to multi-level security. The system is versatile and has been a valued addition to research in MLS system development. In regards to the MLSFS, the relevant aspects of the SeaView model are integrity properties and relational view constraints. These properties preserve the confidentiality of information and outline how the virtual file system is implemented. Sandhu and Chen [24] present the MLR data model, which extends concepts from Denning et al. [9].

4. MLS FILE SERVER MODEL 4.1 MLSFS in MILS The work discussed in this paper assumes that the system is built on a verifiably secure and safe configuration of the MILS architecture. This assumption implies that all communication received by the MLSFS is authentic and authorized by the MILS system and the relevant enforcement mechanisms. Utilizing a MILS based network provides the system with the ability to abstract communication and other related considerations because MILS provides secure communication channels that are mediated by external enforcement mechanisms and frameworks to handle these aspects. These assumptions reduce the need for considerations associated with development and deployment that include secure network communication, authentication, authorization, message integrity, network file systems, source/destination verification, etc. In Figure 4, a MILS system is presented. The MLSFS system interface and corresponding file systems reside in partitions mediated and physically separated by a MILS system. In addition to the MLSFS components are MILS middleware components. They provide additional functionality such as content guarding, message routing and communication integrity.

When the MILS system receives a request message for the MLSFS, it forwards it to the file server interface. The interface interacts with the necessary file systems to execute the request and puts the results on an outbound communications port. The MMR intercepts the message and forwards it to the necessary guards to verify content and/or integrity. Afterwards, the MMR sends the message to the receiving partition, which may be on the same MILS system or a networked system. This general architecture is an important aspect of how the MLSFS system functions. The use of MILS components to verify outgoing message content and authenticate message requests is an important aspect of the system. In addition, the separation provided by the separation kernel is fundamental to how the model enforces its security policy.

4.2 Formal Security Policy A formal security policy defines the authorized and unauthorized states of a system [5]. The security policy the MLSFS follows is a combination of the Bell and LaPadula Model and GWVr2. Both policies play a role in defining external access to the system and the internal interaction. Bell and LaPadula [3] developed a formal MLS policy for the United States Department of Defense that became the de facto standard for MLS systems. The policy is referred to as the Bell and LaPadula Model (BLM), or the Bell-LaPadula security policy. BLM is a security policy that’s primary intention is to preserve the confidentiality of information. It defines three properties for mandatory and discretionary access controls. The properties are the simple security condition, the *-property and the discretionary security policy. The last is not discussed because this revision of the model is concerned with only the mandatory policies and does not support discretionary access controls. The simple security policy, also referred to as no read-ups, states that a subject is not permitted read access to objects with security classifications that dominate their credentials [3]. In other words, the confidentiality of information should never be violated. The *-property, also referred to as no write-downs, states subjects cannot write to objects with security classifications their credentials dominate [3]. This provides a restriction of downwards information flow, e.g. a high level user cannot transmit high level information to low level users. Since BLM’s conception, it has undergone rigorous evaluation by different members of the academic, professional, military and government communities. For instance, Landwehr et al. [17] point out a glaring hindrance in the BLM. Due to the strict preservation of confidentiality, BLM does not permit high level users to re-classify content to lower levels. This poses a problem because in the real world information may declassify over time, or as Landwehr et al. [17] points out, subjects may want to send selected content to lower level subjects. In both cases, BLM does not permit such action. For additional critiques of BLM, refer to McLean’s [19] analysis of BLM. The reason we use BLM as the primary policy for the MLSFS model is that it has been proven to be secure. The amount of rigorous evaluation it has undergone shows its limitations and restrictions, as well as its benefits. Using BLM, we know exactly what we are getting and expecting the system to adhere to. In addition, BLM is the de facto standard for MLS applications and can be found in existing applications. It makes sense to use BLM and show how legacy applications can interact within a MILS environment. MILS components such as a content guard or

downgrader can be used to get around the restrictions of BLM, yet maintain the security requirements of BLM for the application. Greve et al. [11] introduced a formal security policy for a separation kernel, which Alves-Foss and Taylor [1] refer to as the GWV policy. The policy, as described by Greve et al., states that only memory segments allowed to interact with a partition can modify its state. The underlying concept is non-interference via separation. In respect to infiltration and exfiltration, the modification of one partition has no effect on the state of another partition and the state of a partition should not affect the execution of other partitions. Greve et al. provide an ACL2 proof to show the policy’s validity and example of a separation kernel with a firewall application to show its practicality. However, Alves-Foss and Taylor’s [1] critique of the research revealed the limitations of the GWV policy. The policy was vague with undefined assumptions. Alves-Foss and Taylor provided a counterexample to the firewall model; they introduced an additional monitoring partition that was able to violate the GWV policy by writing to a state it was not intended to have access to. Furthermore, the GWV policy was defined in a specific nature and lacked application to general distributed systems. Greve et al. [12], with an additional author, revised their original work to produce a second separation-based security policy that utilized concepts from their original research and Alves-Foss and Taylor’s critique. The authors took the original GWV policy and showed how the policy can be manipulated to achieve the same goal on generalized distributed systems. The new separationbased security policy, which we refer to as the GWVr2 policy, is more generalized. The notion of a single active partition is replaced with multiple active partitions, or agents, and the policy of authorized interaction is extended to account for agents. This adjustment in the policy makes it more extensible and provides support for dynamic behavior. The GWVr2 policy clearly has its usefulness in the development of an application that functions on an architecture that is distributed, multi-level and uses separation kernels to mediate inter-partition and network communication. The MLSFS fits all three characteristics. The GWVr2 policy plays a pertinent role in defining the direct interaction allowed (i.e., authorized information flow) between file system partitions and users. It is expected that a file server operation conducted on one file system partition does not affect the state of another. Confidentiality is a primary concern when considering a subject’s access to information stored in the MLSFS. As such, BLM’s simple security condition is considered for all read operations that access data within the MLSFS’s file systems. A subject can read objects in file systems if their security credentials dominate the target’s credentials. The *-property is, however, handled differently than how it is defined by Bell and LaPadula. The notion of write-ups is restricted in the MLSFS security policy. Allowing write-ups pose complications in maintaining the file systems, e.g.. a low level user can randomly write data to high level file systems and interrupt high level user’s view of the system. Sandhu [25] discusses the notion of a strong *-property, which is a restricted version of the *-property introduced by Bell and LaPadula [3]. The strong *-property restricts a subject’s write access to objects with the exact same security classification. This is somewhat similar to the exact match security policy introduced by Williams and Dinolt [28], the restriction Bertino et al. [4] imposed upon their secure file system model and the security

policy presented by McNamee et al. [20]. The strong *-property addresses the issue by not permitting a subject to write to objects outside of their security credentials. GWVr2 is adapted to consider the direct interaction allowed between active file systems and the related file server operations that can be executed and consequently, modify their states. The fundamental concept in regards to BLM is that a high level subject’s interaction with the file systems should not affect the state of low level users. In other words, if a high level user modifies a file system, whether high level or low level, the low level users should not be able to identify any of these changes. However, there may be cases where the strong *-property or the simple security condition are violated if the interaction is clearly permitted by GWVr2. Together the security policies Bell-LaPadula and GWVr2 are used in tandem to define another security policy that this paper refers to as the MLSFS security policy. This policy provides the necessary enforcements to maintain confidentiality of information flow and benefits from separation and non-interference when considering MLS applications. The key points are summarized in the following: •

Preserves the confidentiality of information flow by asserting low level users are not permitted to access high level data.

•

Maintains confidentiality of information flow by preventing high level users from sending high level data to low level users.

•

Provides file system integrity by disallowing low level users from randomly writing bits to high level file systems. Users can only write to their own levels.

•

Permits unorthodox cases that a subject may be given security credentials to violate the BLM properties in accordance to GWVr2, e.g. granting a user the ability to downgrade (or upgrade) information across domains.

R3. The root may contain objects that have security credentials with varying non-hierarchical components. In other words, objects directly contained in the root folder must have matching rank and class while the compartments may differ. This requirement is an exception to R2. If all three requirements are met, the file system is pseudo-SLS (PSLS) and adheres to the requirements of the MLSFS system. The reason the notion of PSLS is required is that the MLSFS supports multiple security lattices. Users may interact with a multiple file system collections from distinct security hierarchies. While the file system design focuses on a tree-based directory structure, the MLSFS concepts are applicable to database-oriented file systems. In an early iteration, we considered a design with a database-oriented file system, where the parent/foreign key relationship determined the file system’s directory structure. The concept was disregarded for a tree-based structure because of the formal methods tool ACL2’s inherent ability to hand tree data structures. However, we assert the design can easily be tailored to fit database-oriented file systems—partly due to the fact that a significant portion of the design is based upon research in MLR database systems.

4.4 Directory Views A directory view is a conceptual notion based on Irvine’s [15] research and the MLR database systems [9][24]. The directory view, also referred to as a view, is the heart and soul of the MLSFS model. A view is a user-specific interpretation of a collection of file systems. The intent is to build a MLS entity for the user to interact with by considering what the user is permitted to access in accordance to their security credentials and the system security policy. The MLS entity is generated from multiple PSLS file systems to portray to the user a virtual MLS file system.

R1. All data within a file system has the same underlying security level, i.e. the same rank in the security hierarchy. If the root directory of a file system is top secret, then all file and folder objects contained in that file system must be top secret. However, the compartments may vary in accordance to R3.

Directory views are a direct interpretation of Irvine’s [15] research, which presented the concept of a virtual multi-level file system (VMLFS). The VMLFS generates user-specific directory tree structures, which are determined by the user’s security credentials. When a user makes a query to the file server, a directory tree specific to the user’s security credentials is returned. The MLSFS view concept simplifies the VMLFS process and produces a similar effect. The major differences are the underlying backbone and how the data is stored in the system. Since the MLSFS utilizes MILS, there is direct support for logically and/or physically separated data. The file system data is separated by their security credentials, whereas the VMLFS does not necessarily separate data. Instead, it uses aliasing and symbolic links to simulate separation and build unique interpretations of the system based upon security credentials. Separating data by its security classifications allows the concept of separation to be applied to show non-interference of the file server operations to the file system not directly effected. In addition, file system separation allows for file systems to exist on local and remote systems, which in turn permits a networked file system and the directory view concept projects to the user a single, local file system.

R2. A child object must have the exact same security label as its parent. This includes both hierarchical and compartmented components. For example, a top secret NATO folder can only contain top secret NATO information and must be contained in a top secret NATO folder.

The MLSFS view concept extends the VMLFS design by integrating key properties in MLR database research conducted by Denning et al. [9] and Sandhu and Chen [24]. The properties provide application-independent integrity rules that include entity integrity, referential integrity, polyinstantiation integrity, databorrow integrity and view class integrity. The benefit of these

•

MILS system components ensure logical and physical separation of time and space between file systems.

•

Operations conducted on one file system do not affect the state of another file system. In other words, a high level user’s action does not interfere with a low level user’s view of the system.

4.3 File System Structure The MLSFS model uses a tree data structure to represent file systems. A file system root consists of a folder, which may contain additional folders and files. The file system structure follows three constraints to maintain security requirements.

properties provides the model with the capability to produce dynamically formed multi-level file systems. The idea is to make the subjects believe they are interacting with a MLS file system when they are in fact interacting with selected portions of multiple PSLS file systems. The properties are outlined and their relevance to the model is discussed in the following paragraphs. Entity integrity ensures that all accessible components of the primary key to a user are non-null and exist [9][24]. It cannot be directly applied to the MLSFS since in context to a PSLS file system it implies that objects are MLS, but objects are SLS in this system. However, we can infer that all objects dominated by a subject’s security credentials should not be null and the subject should be provided access to the objects. Referential integrity states that if a foreign key is accessible to a user, then any primary keys associated with the foreign key are also accessible to the user [9][24]. In addition, to meet security policy requirements, the foreign key’s security credentials must dominate the referenced primary keys. It applies to the model in that a directory view created for a given subject should include all objects in the file systems dominated by the subject’s security credentials. Irvine’s model allows the deletion of objects (their symbolic links). Effectively, a user can delete a symbolic link to a file and eliminate access to the file for all users in its class (the file may still exist to users outside of the class). To overcome this issue, we opted to follow the referential integrity property and disallow such an action. Polyinstantiation integrity states that there cannot be duplicate primary keys [9][24]. It follows that multi-level primary keys can be defined in a combination of primary key values and security credentials. In regards to the MLSFS, polyinstantiation integrity provides a method to handle multiple instances of objects in directory views. Since views produce different aspects of the system based on security credentials, some subjects may have access to objects others do not. In such a case, both the low and high level subjects may create files or folders within the same directory path and unique identifier (object’s name). This circumstance poses a problem and the concept of polyinstantiation integrity presents a way to handle multiple instances of objects segregated by security classification, which is the binding of directory path, object name and security label denote the uniqueness of an object. Data-borrow integrity states if a high level subject modifies a low level object, the modified object (not the original) will be automatically upgraded to the high level subject’s classification [24]. The property cannot be directly applied because the MLSFS does not incorporate an active automatic upgrading mechanism for high level subjects that manipulate low level objects. Instead, the general concept is applicable (and it follows the strong *property) and subjects trying to modify low level objects can only write those objects to file systems with matching security credentials. View class integrity states the class associated with the view dominates referenced views and relations [9]. It is also implied the referenced views adhere to view class integrity property. In context to the MLSFS, the property defines that a directory view must include all objects from the file systems that are dominated by the subject’s security credentials. This property is similar to the use of referential integrity. However, it more explicitly states which objects should be included in a given user’s view.

4.5 Data Structures The MLFS consists of three primary data structures that consist of security labels, file/folder objects and messages. Security labels determine whether a subject’s security credentials permit read, create and/or delete operations to be conducted on an object in accordance to the system security policy. File/folder objects represent the system’s data and organization. A file system is represented by a collection of nested folder and file objects. Messages are objects used to determine what operation to conduct on which file systems and whether or not the initiating subject has valid security permissions to make the invocation.

4.5.1 Security Label Data Structure

Figure 5. Security label data structure. Security labels are used by both subjects and objects to determine whether or not a subject should be allowed access to an object (or objects). Specifically, security labels are evaluated to establish a dominance relationship in accordance to the system’s information flow policy. The security label object, Figure 5. consist of the following: •

Class: denotes a value that represents which security lattice the current label belongs to.

•

Rank: denotes the level within the hierarchy.

•

Category: denotes the compartment associated with the rank, e.g. NATO.

In addition to security labels, security range objects are used. They consist of two security labels, which denote the maximum read and minimum write permissions. Each security range is used to represent a subject’s security credential in a particular security hierarchy. The concept of the maximum read and minimum write levels follows Foley’s [10] information flow model. It is important to note the read and write levels do not have to be the same values. A subject may have a maximum read level that is greater than the minimum write level. For example, a subject may have read level top secret and write level secret. While this setup allows information to flow from high to low levels, thus violating Bell-LaPadula, GWVr2 permits instances where information flow may travel from high to low level sources if the interaction is specified.

4.5.2 File/Folder Data Structure FILE/FOLDER DATA STRUCTURE Name

Content

Security Label

Attributes

Folders

Files

Figure 6. File/folder data structure. The file/folder object data structure represents files and folders that are used to build file systems. Representing files and folders with a single object was selected because the two share common base components such as name, security label, and general

attributes. However, they differ in that files need to have some kind of content (data value) while folders need to store information about files/folders they contain. File systems are built from the bottom up. A folder acts as a root directory and stores children files and folders. As shown in Figure 6, the object data structure is a generic container that can represent a file or a folder. The fields provide the following: •

Name: a unique string used to identify the object in the context of a path. A path is a list that contains a list of nested names that correspond to the directory’s location containing the object.

•

Content: a field that represents file contents. In the case of a functional implementation, this might be the address on the hard disk and block size. This component applies only to file objects.

•

Security Label: the corresponding object’s security credential.

•

Attributes: a list of individual file/folder attributes such as time/date of creation, last accessed and last modified. This field can be extended to support other information such as user name, group membership and other data commonly associated with files and folders.

Since the system supports multiple security lattices, subjects may have multiple security credentials. A user is made up of one or more security range objects. However, we only consider users having multiple security credentials in disjoint security hierarchies. It is possible for a user to have multiple security credentials from the same security hierarchy, but it is not explicitly considered in this model. If it was specified in the direct interaction allowed per the GWVr2 policy, it would be possible. The user would act as a trusted cross-domain service. The operation field contains a path defined in the subject’s directory view (the path must exist in the file system corresponding to the target object), a file/folder object and operation tag. For example, a message with an operation tag CREATE-FOLDER will attempt to create the folder OBJECT in the PATH of the virtual file system. The system will, however, determine the actual PSLS file system that PATH corresponds to OBJECT’s base security level. If the PATH is invalid to the file system corresponding to the OBJECT’s base security level, the operation will not be successfully completed. The message object’s fields, shown Figure 7, are the following: •

Read/Write Range: the user header consists of one or more read/write ranges. The ranges contain an upper bound (highest read access) and a lower bound (lowest write access) in a given security hierarchy [10].

•

Folders: a list of folder objects contained within the object. This component applies only to folder objects.

•

•

Path: the path in the file system corresponding to the target object where the operation should take place.

Files: a list of file objects contained within the object. This component applies only to folder objects.

•

Object: the target of the operation, e.g. file/folder to create, delete or read.

•

Operation Tag: a tag that denotes the type of operation

4.5.3 Message Data Structure MESSAGE DATA STRUCTURE

o

CREATE-FOLDER: tag that indicates to the file server to create a folder.

o

DELETE-FOLDER: tag that indicates to the file server to delete a folder.

o

LIST-DIR: tag that indicates to the file server to list directory contents.

o

CREATE-FILE: tag that indicates to the file server to create a file.

o

DELETE-FILE: tag that indicates to the file server to delete a file.

o

READ-FILE: tag that indicates to the file server to read the contents of a file.

Read/Write Range Path

Object

Operation Tag

Figure 7. Message data structure. Messages are used in the model to issue commands to the file server, e.g. to create a folder or read a file. A message is comprised of two major fields, user and operation. These fields are not explicitly shown in Figure 7. Instead, the component breakdown of user and operation are presented in the figure. The user field is intended to model user security credentials and it has been designed as a history-free process. In future work, if an auditing system is implemented more specific information about the subject invoking the command may be required. The user field would contain this information. Or information about the username and/or group membership could be included in the user field to support discretionary and/or role-based access controls. At this time, the file server uses the user field to define the subject’s read and write permissions to process an operation. It is assumed that an external mechanism, MILS middleware, verifies the subject submitted the proper security credentials in the message to the MLSFS. As previously described, the read and write credentials are stored in security range objects. Security range objects are a pair of security label objects [10]. The first label represents read permissions and it is an upper bound value that denotes the maximum read level. The other label represents write permissions and it is a lower bound value that denotes the minimum write level.

4.6 File Server Operations The functionality of the file server can be expressed in three basic operations: read, create and delete. Functionality for other operations such as copy and move are not included because they can be reproduced through a combination of read, create and delete operations. For instance, a copy operation would begin with reading a file into a buffer and writing the buffer to disk, while a move operation would entail reading a file into buffer, removing the file from the disk, and writing the buffer to disk. This approach is taken because it simplifies the operational requirements for designing and implementing the model. The operations function on file and folder objects, with some slight discrepancies between the two. The create operations for files and folders insert file/folder objects into a file system. The delete operations remove a file/folder object from a file system.

Separation Kernel

Network

File Server

Unclassified

Confidential

Secret

Top Secret

MMR

Content Guard

Client B

Client A

MMR

Content Guard

File Systems

Separation Kernel

Figure 8. MLSFS in a MILS network with client partitions.

The read operation for a file retrieves the data portion of a file object from the file system. The read operation for a folder functions differently. It is more complex because of the need to generate the directory views. The folder read operation will compare a subject’s security credentials to all objects that exist in the path in all file systems. Only the objects with security labels dominated by the subject’s credentials will be included in the view.

specification and formal model. The formal specification consists of an abstract grammar that defines the data structures and operational semantics that define how the operations and the abstract machine function. The formal model is an executable model built in the formal methods tool ACL2 that was designed directly from the formal specifications. We intend to show that the model adheres to the formal security policy to satisfy the Common Criteria EAL5+ formal methods requirement.

4.7 MLSFS Interface

Future work that directly relates to the design includes implementing discretionary and role-based access controls, an auditing system, extending the file/folder attributes to model additional aspects of a file system, and investigating performance issues, distributed operational constraints, covert timing channels, further interaction in the MILS system design and operation in database-oriented file systems.

The MLSFS security policy is enforced on the file servers with an additional suite of functions. These functions act as security enforcement mechanisms, type checkers and operational evaluators. The MLSFS uses an abstract machine, also referred to as an interface, to process message commands on a collection of file systems. Conceptually, the interface is the file server component in Figure 4 and Figure 8. Prior to invoking a file server operation, the abstract machine will process several verification and validation functions that include (and not limited to) ensuring the target has read access to the target object, write access to the target file system, checking for existing objects before creating one in a file system, and ensuring all objects are specified correctly and well-typed. The interface, as depicted in Figure 8, resides in a MILS partition. When the MILS system receives a file server request message (it can come from client partitions the local MILS system or remote client on another system,) the MILS system will deliver the message to the MMR. The MMR will send the message to the interface, which will process it as necessary. The interface will generate subsequent communication to interact with the file systems and conduct the operation the MLSFS was requested to accomplish, considering all the security verification and operational validation checks were not validated.

5. CONCLUSION High assurance systems, where the level of criticality can result in loss of life, financial disruption or other negative high-impact incidents produce a need for certifiable, verifiable and evaluatable system development. Common Criteria serves as a certification process that can be used to evaluate the level of assurance in hardware/software systems. In this paper, we presented the design concepts of a high assurance file server, which included a detailed overview of the underlying architecture MILS, pertinent research that we extended, formal security policy, data structures, operations and how it all ties together. The work presented in this paper is a starting point for a larger body of work, where we will use the design to develop a formal

Another direction we wish to pursue is incorporating storage security systems into our design. Our current research efforts have focused on MLS and the mediation of information flow. In future work, we will adapt secure file systems into the MLSFS and MILS. For example, if a hard disk is stored at a remote facility, e.g. in possession of a contractor, the data on the hard disk needs to be secured (encrypted). Our current design does not address situations like this, however the separation of the MLS systems into individual single-level systems allows for the deployment of MLS file systems using commercial secure storage solutions that do not support MLS. Solutions can be found in systems such as the work surveyed in [22]: Cryptographic File System, Secure File System, Cepheus, Secure Network-Attached Disk and Network-Attached Secure Disks, as well as Secure Untrusted Data Repository [18] and Plutus [16].

6. ACKNOWLEDGMENTS This material is based on research sponsored by AFRL and DARPA under agreement number F30602-02-1-0178 and the NSF SFS grants DUE–0114016 and DUE-0416757. The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright notation thereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expresses or implied, of NSF, AFRL and DARPA or the U.S. Government.

7. REFERENCES [1] Alves-Foss, J. and Taylor, C. An Analysis of the GWV Security Policy. ACL2 Workshop 2004. Austin, TX, Nov. 2004.

[2] Alves-Foss, J., Harrison, W. S., Oman, P., and Taylor, C. The MILS Architecture for High Assurance Embedded Systems. In International Journal of Embedded Systems, in press. [3] Bell, D. E. and LaPadula, L. Secure Computer System: Unified Exposition and Multix Interpretation. ESD-TR-75306. Bedford, MA, MITRE Corp., 1976. [4] Bertino, E., Jajodia, S., Mancini, L., and Ray, I. Advanced Transaction Processing in Multi-level Secure File Stores, IEEE Transactions on Knowledge and Data Engineering, 10, 1, Jan/Feb 1998. [5] Bishop, M. Computer Security: Art and Science, AddisonWesley Professional, New York, NY, 2003. [6] Canadian System Security Centre, Communications Security Establishment, The Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) Version 3.0e, January 1993.

[16] Kallahalla, M., Riedel, E., Swaminathan, R., Wang, Q., and Fu. K. Plutus: Scalable Secure File Sharing on Untrusted Storage. In Proceedings of the Second USENIX Conference on File and Storage Technologies, Mar. 2003, 29-42. [17] Landwehr, C., Heitmeyer, C., and McLean, J. A Security Model for Military Message Systems, ACM Transactions on Computer Systems, 2, 3, Aug. 1984, 198-222. [18] Li, J., Krohn, M., Mazières, D., and Shasha, D. Secure untrusted data repository (SUNDR). In Proceedings of the 6th Symposium on Operating Systems Design and Implementation, San Francisco, CA, Dec. 2004. [19] McLean, J. A Comment on the Basic Security Theorem of Bell and LaPadula, Information Processing Letters, Vol. 20(2), Feb. 1985, 67-70.

[7] Commission of the European Communities, Information Technology Security Evaluation Criteria, Version 1.2, June 1991.

[20] McNamee, D., Heller, S., and Huff, D. Building Multilevel Secure Web Services-Based Components for the Global Information Grid. CrossTalk: Journal of Defense Software Engineering, 19, 5, May 2006, 15-19.

[8] Common Criteria for Information Security Evaluation, Part 1: Introduction and General Model, Draft Version 3.0, Revision 2, CCMB-2005-07-001, June 2005.

[21] Richards, R., Greve, D., Wilding, M., and Vanfleet, W. M. The Common Criteria, Formal Methods and ACL2. ACL2 Workshop 2004, (Austin, TX, Nov. 2004).

[9] Denning, D. E., Lunt, T. F., Schell, R. R., Shockley, W. R., and Heckman, M. The SeaView Security Model, IEEE Symposium on Security and Privacy, 1988, 218-233.

[22] Riedel, E., Kallahalla, M., and Swaminathan, R. A framework for evaluating storage system security. In Proceedings of the Conference on File and Storage Technology, Monterey, CA, Jan. 2002, pp. 15-30.

[10] Foley, S. N. A Model for Secure Information Flow, IEEE Symposium on Security and Privacy, 1989, 248-258. [11] Greve, D., Wilding, M., and Vanfleet, M. V. A Separation Kernel Formal Security Policy. ACL2 Workshop 2003, (Boulder, CO, Jul. 2003). [12] Greve, D., Wilding, M., Richards, R., and Vanfleet, M. V. Formalizing Security Policies for Dynamic and Distributed Systems. Sep. 2004. [13] Hall, A. Seven Myths of Formal Methods, IEEE Software, 7, 5, Sep./Oct. 1990, 11-19. [14] Harrison, W. S., Hanebutte, N., Oman, P., and Alves-Foss, J. The MILS Architecture for a Secure Global Information Grid. In CrossTalk: Journal of Defense Software Engineering, 18, 10, Oct. 2005, 20-25. [15] Irvine, C. E. A Multilevel File System for High Assurance. In Proceedings of IEEE Symposium on Security and Privacy (Oakland, CA, May 8-10, 1995). IEEE, 1995, 78-87.

[23] Rushby, J. Design and verification of secure systems. ACM Operating Systems Principles, Dec. 1981, pp. 12-21. [24] Sandhu, R., and Chen, F. The Multi-level Relational (MLR) Database Data Model. ACM Transactions on Information and System Security, 1, 1, Nov. 1998, 93-132. [25] Sandhu, R. Relational Database Access Controls, Handbook of Information Security Management (1994-95 Yearbook), Auerbach Publishers, 1994, 145-160. [26] United States Department of Defense, Department of Defense Trusted Computer System Evaluation Criteria, DoD 5200.28-STD, December 1985. [27] Wahsheh, L. A., and Alves-Foss, J. Specifying and Enforcing a Multi-Policy Paradigm for High Assurance Multi-Enclave Systems. Journal of High Speed Networks, 15, 3, Oct. 2006, 315-327. [28] Williams, J. C., and Dinolt, G. W. A Formal Model of a Trusted File Server, IEEE Symposium on Security and Privacy, 1989, 157-166.