A Multilevel Security Model for a Distributed Object ... - CiteSeerX

Download PDF
26 downloads 326 Views 1MB Size Report
Comment
We consider the basic concepts of the object paradigm .... to the development of information flow security policies for a distributed object oriented system and ...
F.f..- HEWLETT

a:~ PACKARD

A Multilevel Security Model for a Distributed Object-Oriented System Stewart Black, Vijay Varadharajan Networks and Communications Laboratory HP Laboratories Bristol HPL-90-74 June, 1990

multilevel security, information flow, object model

It often suggested that distributed computing will be the major trend in computer systems during the next decade. However, distributed systems are vulnerable to a number of security attacks. In this paper we look at the security problems of object-based distributed systems, and propose a model based on labeling for multilevel security. The purpose of this model is to preserve the information flow security in a distributed object-oriented system.

We consider the basic concepts of the object paradigm, and also the security threats to such systems. We postulate various modeling possibilities, and produce a specific set of security properties which describe a multilevel secure object model. This particular model should not be considered as a panacea, but rather should demonstrate how the various modeling decisions are reflected in an actual model. We conclude with a discussion of possible avenues of future research.

© Copyright Hewlett-Packard. Company 1990

1

Summary

This paper discusses the issues in multilevel secure object systems. In particular, we look at multilevel information flow security models for an object-oriented system, based on the use of security labels. Most of the existing work to date has been based on assigning labels to the objects, and is concerned with database systems [9], [10]. However, we consider more general object syst~ms, existing in a distributed environment. Our approach takes a fine grained security model, with labelling at ,the variable, method, and message level. The concern of this paper is to look at generic systems of objects, and to see what are the implications for information flow security. As we consider objects in fine grain, and also in a distributed environment, we have information flow at the inter and intra object level. At the inter object level, objects are communicating via asynchronous message passing. At the intra object level, methods are reading and writing instance variables. With this fine grained view of labelling, we ask questions about the relationship between labels of variables, methods, and messages. This relationship depends upon how much control we can have in checking during run-time that the security constraints are being satisfied. We assume that the object management and run-time checking is done by trusted processes, and that the underlying communication can also be trusted. This paper can be seen as an 'op~ner' for security policies for distributed object systems. We point to possible further work in multilevel- secure object models, and also towards additional models, such as discretionary access control. The particular information flow security model that we have considered here is prima.rily concerned with the mandatory security aspects. In addition to this, it is necessary to consider the discretionary security issues. In an object-oriented system, the natural point of control for discretionary access is the reception of a message at an object. The message should be refused if it comes from an object (or acting behalf of an object) who is not authorized to send the given message to that object. In such a scenario, we need to consider the issues such as how are authorizations expressed, stored and propagated and how are the discretionary controls enforced? We envisage such a discretionary security layer to be specified "on top" of the proposed information flow security model.

2 2.1

Introduction Background

The last ten years has seen the rapid growth in networked computer systems. Networks allow a number of computers to electronically exchange information with each other. This has presented a great opportunity for the sharing of computer resources (such as processing power, storage, printing), and we are 'now beginning to see the exploitation of this opportunity. The phrase. 'distributed computing' is used to describe the potential that a network of computer systems can offer. Over the years there has been a great deal of interest in distributed

2

compu~ing, but

it is

only now that we are beginning to see the commercial possibility of this technology. There has been a considerable amount of effort in the area of distributed data and files, with the Xerox XDFS [13] and Apollo Domain [11], and also in 'distributed processing' (see [14] and [5]), where co-operating processes may be residing on different host machines. It is the distributed storage and maintenance of information, and the distributed processing of the information that characterises distributed systems. Another, independent, technology has developed at the same time, namely that of 'objectoriented programming' ([15], [12], [6]). Essentially object oriented programming evolved from a programming design methodology, with "clean" and minimal interfaces between programme modules. Unlike the more familiar programming methodologies based upon functional design, the object-oriented approach is based .on the data. The modules of the system are not functions, but data and operations specific to that data. This modularity was also driven by another concern - re-use of programme components. A number of programming languages evolved embodying these concepts, most notably Smalltalk [8]. The object-oriented programming approach is a step forward in software quality and re-use, and is gaining in popularity. One of the advantages most commonly cited for adopting the object approach is that it is a more "natural" way of capturing real-world situations within a programme. It is easy to see that the object concepts, of self-contained, encapsulated data entities communicating with other such entities, are easily paralleled within real distributed systems. The advantages of distributed computing are well publicised. However, there is a price to pay for having your information being communicated and processed on many machines, without having direct control on each of these machines. The price, of course, is that you do not have complete control on the management of your information so that it may be subject to alteration, deletion, replication, and unauthorised disclosure. Hence distributed systems are more readily prone to security threats, and therefore demand a much greater need for suitable security measures to avert them. A typical security problem in a distributed environment is that of "leakage of information" , whereby an entity that is authorised to "see" certain information may disclose this information (or "leaks" it) to unauthorised entities. One can overcome this "leakage problem" by enforcing suitable flow policies which restrict the flow of information between different system entities. Typically in the lattice model of information flow [7], the system entities are assigned "security labels" and the control of flow of information between two entities is regulated using these security labels. These labels signify different levels of sensitivity associated with the entities. In this paper, we will be addressing the key issues related to the development of information flow security policies for a distributed object oriented system and proposing a multilevel information flow security model.

2.2

Roadmap

The remainder of this paper is as follows: first, in Section 3, we shall look at the basic concepts of objects, and then shall consider mere complex, and realistic problems of objects, such as object creation, .deletion , and design issues such as inheritance. Section 4 considers multilevel security in more detail, and the use of labels assigned to information 3

and processing components of a system. This is followed by a detailed consideration of the issues in a multilevel secure object model based on security labels in Section 5. In this section, we begin by considering the potential threats to a distributed object system. Then we consider the granularity to which security labels should be assigned to components of the system. Also we look at the granularity of the underlying object manager (monitor), and how security labels are assigned and changed during the system lifetime. Section 6 proposes a particular model and describes its security properties, so as to exemplify the approach to formalising our model. There is then a discussion of possible future development of this work in Section 7.

3

Object System

In this section we shall briefly describe object models of different complexity. It is not our intention to give a formal description here, as a more detailed account can be found in (3]. However, we shall give sufficient detail so that we can explain how multilevel security relates to the object model. In section 7 we shall mention more on the formal aspects.

3.1

Basic Concepts

The first questions we want to answer are 'what is an object?' and 'how do objects interact with each other?'. In solving these questions we do not consider more detailed questions such as how objects are created, how they are designed, and how they relate to each other. We shall describe a picture of static objects that exist throughout the lifetime of the system, and which are the only objects within that system.

An object in our system consists of data encapsulated by a fixed number of methods (operations). That is, the only way the data can. be accessed (read from or written to) is by invoking (calling) one of its methods. The data of an object can be stored in state, or instance variables. Each method of the object may access some or all of the object's variables, may interact with other objects, and may perform transformations (computations) on the object's variables, and variables local to the method. The interaction between objects is by messaging. Objects can only communicate with one another by sending messages to each other's interfaces (so no shared variables). The interface to the method is all that a user of the object is concerned with. The message structure relates to the method interface, and not necessarily to the method internals, or implementation. In our model it is important to notice that there are essentially two kinds of messages, namely those requesting the invocaiion of a method (the "call"), and those returning the result ofthe method invocation (the "return"). The reason that we distinguish the call from the return is that in both cases data may be communicated between objects. In real distributed systems objects may be at remote sites, and so may be communicating over an underlying network. It is natural, therefore, to model the messaging as asynchronous 4

communication. If we do not wish to consider the possibility of underlying network errors, then we could use a synchronous model, where communication events can be considered as shared, atomic interactions. (Note that there are several definitions of synchrony. In this instance we are not referring to the request/confirmation model.)

3.2

Static/Dynamic Model

The above describes a picture in which we have a number of objects that exist at some time, and that interact with each other by invoking each other's methods. This picture is too simplistic for realistic situations. Most applications require the possibility of the creation and deletion of objects within the system. Let us consider a system (of objects) that contains information on employees. There are objects in the system that represent employees, and each employee object contains information on the employee, such as name, address, and salary. Each employee object also has methods (operations) for accessing (reading/writing) the information on each employee. In such a system we may typically want to create new objects as employees join the company. Similarly we may also have occasion to remove objects from the system! The object oriented concepts of class and class template are necessary when considering dynamic systems of objects. If we wish to create new objects, then it is necessary to say what kinds of objects we want in terms of what information they should contain, what operations they should have, and also what their implementation is (though this last point may not be of concern to other objects in the system). The concept of template allows us to make statements such as "create me an object with the state variables and methods of this template, and assign these values to the variables of the object", or more briefly " create me one of those". The template describes the implementation, or realisation of the required object. It combines the user's view of the object (the interfaces) with the internals (state variables, and method implementations). In other words, a class template is a. template from which a number of similar objects can be constructed. A template can be re-used for constructing objects with similar features (such as the types of the state variables, and the methods). When requesting the creation of an object, the class template acts as a shorthand for describing the kind of object that we wish to create. An analogy can be drawn between the procedure definition and a procedure instance, and a class template and an object. The word 'class' is used to associate all objects that in some sense satisfy the class template. Although this concept is not used by objects, it is useful in allowing us to discuss objects. In the example above of a company's personnel information system, we have an object for each employee. We use a template for employee objects, so that each employee object is just an instance of the employee template. The class of employee objects is the set of objects that are derived from the employee template.

5

3.3

Design Issues

In adding the possibility for objects to be created and deleted, we have to make some decisions as to how creation and deletion should be handled, who should be allowed to create and delete objects, and whether there are any relationships between the creating and created objects. In the previous section we have considered the use of templates for creating objects. We have not considered though how we may request the use of such a template, and with whom we should lodge our request.

One approach commonly used for the creation and deletion of objects in object oriented programming languages is to use the concept of factory ([12]). A factory object is a special kind of object that represents a manager of objects of a specific class template. In the creation and deletion of objects, the messaging concept is maintained. A factory object has methods for creating and deleting objects of a certain class, and manages the creation and deletion of these objects (as well as identification). Going back to the example of the personnel system, we would have an employee factory object. Every time we wanted to add a new employee object, we would send a 'create' message to invoke the 'create' method of the factory object. The factory object would then create an instance of an employee object, assigning values to variables (according to the create request), and would return a 'handle' to the requesting object, so that the new object can be uniquely identified. The factory object is responsible for mapping the information in a create request from a user to the newly created object's internal representation. The user does not need to know how the information is stored in the new object, and neither how it is implemented. The user does expect the new object to .have a well-defined interface, and that the factory faithfully implements the behaviour of the required object. Deletion of objects is also an important issue. There are a number of possibilities for deletion, such as deletion via factory objects, allowing only the object itself to request its deletion, only allowing the creating object to request the deletion of one of its "children", and deleting all "children" when a "parent" gets deleted. However, deletion is less important from a modelling point of view, as an object can be ignored if it is no longer used. Within real implementations we do have finite resources, and so memory management, and object deletion, are important. Re-usability is another advantage of the object oriented approach. Above we have discussed the re-use of the template to create several objects of the same kind. This is both a design issue and a (dynamic) run-time issue. The concept of re-usabillty can be applied at designtime, with the concept of inheritance. This is an extremely important concept in object oriented programming languages, and there is a lot of research on this topic (see (1], and [4] for example). However, it is less important for our model, so we shall treat it rather superficially. For our purposes, inheritance is a mechanism for constructing templates from existing templates. That is, to create a new template we can 'inherit' the description of state variables and methods from existing templates, and extend the template as we desire. Thus we are re-using templates in designing new templates. However, this re-use does not affect our general object model, though it does open some interesting questions regarding trust of inherited templates, and additionally some security considerations on implementing mechanisms for inheritance.

6

4

Security Policy

A security policy is a description of the needs and requirements of a system to compensate for, or protect against, various threats to the system. This is a high level declarative description reflecting the security problems faced by the system. A security model is a representation of the security policy and deals with the security properties (such as rules and constraints) of the system. The security model is abstract and generic and should only contain information pertinent to the security aspects of the system. To determine the security requirements, first we need to identify the threats faced by a distributed object system. Let us consider some such typical threats.

4.1

Threats

The following is a list of some typical threats to information security in a distributed object system. With each possible threat is identified a class of policies and mechanisms that are intended to prevent the threats from occurring. 1. Unauthorized Access to Objects: This class of threats is essentially concerned with

an object accessing another object (e.g. invoking a method in another object) for which it has no authorization. It also includes threats against propagation of authorizations. To counteract such threats in anobject-oriented system, the natural point of control is the reception of the message at an object. For instance, one can propose a scheme whereby each object has associated with it some access control inforination (e.g. access control lists ) which can be used to determine whether the received method call from a given object should be granted or not. We may either state who may be allowed to invoke a method, state who may not be able to invoke the method, or state that only objects with certain properties (attributes) may invoke the method. Then we can develop suitable mechanisms to prevent misuse in access control information propagation. Such policies form part of a discretionary access control model for an object-oriented system and they will be addressed in a separate paper.

2. Unauthorized Information Flow: By information flow control, we mean that the flow of information between two entities must be suitably restricted not to violate a prescribed set of flow policies. For instance, when information is transferred between objects during messaging, we wish to ensure that the flow of information does not contravene our flow policy. This paper is primarily concerned with such information flow security policies for an object oriented system. Such an information flow model addresses the mandatory security issues of an object-oriented system. In fact, we view the discretionary access control model to be "on top" of the information flow (mandatory security) model for an object system. 3. Identification and Authentication: Implicit in the above two requirements is that an object can be uniquelyidentified. However, we do not just require unique identifiers, but also a guarantee that the identifier does in fact belong to the object whom it claims to be. We do not. want to allow objects to masquerade as other objects by falsifying their identifiers. Policies and mechanisms to implement such guarantees fall within the notion of authentication. 7

4. Data Protection: Finally we need to protect the communications themselves. There are a number of possible threats to communication which are the domain of communications security. The main approach to providing communications security employs cryptographic techniques. We shall not be concerned with this aspect in this paper. There may be "other security threats to the distributed object environment, such as the denial of service. Informally, the denial of service is said to occur when an object makes a specified service unavailable to another otherwise-authorized object for a period of time that exceeds the intended waiting time. We shall not be addressing these other possibilities. Before we look at a multilevel security model for an object-oriented system incorporating information flow security properties, it will be useful to briefly describe the concept of multilevel security and some associated teminology.

4.2

Multilevel Security

The information handled in multi-user systems typically has different levels of sensitivity associated with it. Some information is likely to be more important than others. Therefore it is necessary to devise some means whereby only some users of the system have access to such information. Again going back to the example of the personnel system, an employee's address may not be considered sensitive information, so all users of the system could access this information. However, their salary may be considered confidential, so that only an employee, her/his managers, and the personnel department, may have access to that information. " So the purpose of multilevel security is to avoid the unauthorised disclosure of certain information to certain "untrusted" users. One mechanism for implementing this policy is by assigning security labels to the information and users of the system. The label represents the level of sensitivity of the information, or the level of sensitivity to which a user is allowed access. This prevents users accessing information with a security label for which they are not cleared. The case of military information systems is typical of the restrictions placed on the information within the system. Each data unit is assigned a classification, such as Unclassified, Confidential, Secret, and Top Secret. Each user (or process) of the system is assigned a clearance. So a user may only view some information if its clearance dominates (see Section 3.2.1) the classification of the information. For instance, a General, who has clearance of Top Secret, may access all information of the system, whereas an Engineer, who has Confidential clearance can view only Unclassified and Confidential information, but not information classified as Secret or Top Secret. The most well-known multilevel security model is the Bell-Laf'adula model [2]. Here a system is viewed as a collection of "subjects" (processes, users) and "objects" (data) 1. Each subject and object is assigned a security label. The behaviour of the system is represented by a set of system states, state transitions, and an initial state. The significant operations allowed in this model include read, append, uecute and read-write. A ~ta.te defines the access that subjects currently have on" objects, and the current security labels associated with the lIn this section, the term "objects" are used in this t~aditional8ense and not in the object-oriented sense

8

subjects and the objects. The Be1l-LaPadula model defines the properties for a state to be secure and suggests the kind of restrictions needed on these operations to preserve these security properties. Modelling information flow is relatively uncomplicated compared with the Bell-LaPadula model. Instead of a series of conditions and properties to be maintained, there is the single requirement that information flows do not violate the specified flow relations. That is, information should not flow to users with a lower clearance. A user should not be allowed to access information whose level of sensitivity is greater than that of the user. When considering the main operations of reading and writing data, this principle is manifested as "no read up, no write down". So, a user can only read (receive) information of a lower clearance than itself, and can only write (send) information of a clearance higher than itself. Typically a classical information flow security model has the following components: • a set of information receptacles (e.g. files, variables etc.); • a set of processes representing active elements responsible for information flow; • a set of security labels (security classes); • an associative and commutative security label combining operator that specifies the label of the information generated by any binary operation on information with two labels; • a flow relation that, for any pair of security labels, determines whether information is allowed to flow from one to the other. One may distinguish between an accesss policy and an information flow policy in the following way: The access policy specifies the rights that subjects have to objects whereas the information flow policy specifies the labels of information that can be contained in objects and the relations between object labels. To some extent, these policies are interchangeable, or at least dependent: restrictions on a subject's access to an object will presumably restrict the flow of information (and hence the information that can be contained in a particular object). Conversely, restrictions on flow will have an effect on what access rights a given subject can exercise for a given object.

4.3

Notation

Before we discuss some of the issues related to the design of an information flow security model for an object oriented system, it will be useful to give here the common definition of the relation "dominate" on the set of security labels - as this relation will be used thoroughout the paper. We assume that a partial ordering ~ is defined on the set of security classes. Given two . security labels sl1 and s12, if sl1 ~ sl2 we say that sl1 dominates s12. It is not always possible to compare two security labels using the "dominate" relationship. In this case, they are said to be incomparable. In this paper, we will further assume that the set of security labels is a lattice with respect to the partial ordering ~. That is given any pair of elements sl1 and sl2 : 9

• the set of all security labels dominated by both sl1 and sl2 is non-empty and contains a unique greatest lower bound (glb) that dominates all the others; • the set of all security labels that dominate both sll and sl2 is non-empty and contains a unique least upper bound (lub) that is dominated by all the others.

5

Issues in a Multilevel Secure Object Model

In order to specify a security model for an object-oriented system, we must first identify the entities that make up the abstract system. As we are considering a multilevel security model providing information flow security, we then need to consider how we can associate security labels to the system entities. This involves considering the different levels of granularity that can be adopted. Following on from this, we need to develop suitable schemes to ensure that there are no breaches of the information flow security policy during system operation. This discussion will help us to clarify what amount of the underlying system needs to be trusted. Finally we shall look at the problem of assigning and altering the security labels of objects in the system.

5.1

Security Labels

With the object model, we do not have such a clear separation between "subjects" and "objects", as in the classical Bell-LaPadula model. The entities of our object system that are relevant from the point of view of assigning security labels include: variables, methods, messages, objects and classes. Each object consists of data variables, each of which could conceivably be assigned a different security label, and operations which may alter the variables' values (and possibly their security labels). The question of where to check the security clearance, whether at the object level, method level, or individual variable level, then needs to be addressed. There is some philosophical debate as to whether it is the information, or the containers of information, that should be assigned security labels. We take the view here that it is the containers ('slots' or 'variables') that should be assigned labels and that the label of the container reflects the sensitivity of its information content. Hence controls that deny access to information are based on the. labels of the containers. For example, what is the label that should be assigned to the integer 1001 Clearly the answer depends on the context, or what it is supposed to represent. AB all values are contained in slots, then it is the slot that models the real-world entity. Thus it is the 'salary' slot in the personnel file that is of semantic relevance, and not the integer value that is contained in the slot. However, there may be a relationship between the range of values that may be assigned to the slot, and the labels that may be attached to that slot. We may sometimes talk about the label of a value as a short hand for the label of the variable containing the value.

10

5.1.1

Labelling Components in the System

In addressing the issue of granularity of security labels we need to consider the following issues:

• What are the relationships between the method and variable labels? • What is the relationship between the message label and the data contained within the message? • What is the relationship between the label of the message and the originating method? • What is the relationship between the label of the message and the receiving method? We have already explained that the purpose of assigning security labels to information and users is to avoid the unauthorised disclosure of information. Therefore it is the data which is sensitive, and must only be disclosed to select users. In our case the data is that associated with the variables of an object (the object's state variables), and the users are the methods (operations) of the objects, which participate in messaging. Variables: Variables in each object have security labels associated with them. To be as generic as possible, we should allow each variable to be assigned a different label. Methods: A method may have a single security label associated with it. This is the case we shall use in most of our discussion. However, in section 7 we consider alternatives to this approach. With a single level, we need the following constraints: (1) the level of the method should dominate the levels of all the state variables that it can read, and (2) the level of the method is dominated by the levels of all the state variables that it can write to. These constraints can be considered also in terms of the input and output levels of a method, which may vary with time, and will be discussed further in section 7. The next step then is to see how labels of the objects' variables relate to the methods of the objects. Remembering that information should only be written up and read down, and assuming that we have single fixed level methods, we can deduce the following properties: • A method in an object has read access to some variables of that object. Thus the label of the method should dominate the labels of the variables it can read. • A method in an object has write access to some variables ofthat object. Thus the label of each variable that can be written into should dominate the label of the method.

• If a method both reads and writes to a variable, then the label of that method should be equal to the label of the variable. Messages Communication via messaging is the most basic level of information flow. It is essential that the message is suitably labelled to avoid the unauthorised disclosure of its contents. As messages are essentially 'one off', we need only assign a single level to a message. In this paper we use the term 'message'· to refer to both the method invocation and the return message (on completion of the invoked method). Using the write up, read down principle, we can deduce the following: 11

• When data is passed between objects during messaging, the label of the message should dominate the labels of the data contained within it. • When a message is sent from one object, A, to another object, B, then the label of B's receiving method should dominate the label of the message sent from A.

• H there is no data passed in the message (such as just a method invocation request, or an acknowledgement that the method has terminated its execution successfully), then the label of the message may be lower than the label of the sending method. The relationship between the label of the message and the label of the method originating the message is discussed in the next section. Objects: So far we have not considered the association between the labels of an object's variables, and the label of that object. In most proposed multilevel security models (such as [9], [10]) the lowest level of granularity is that of the object. That is, in these models it is only the objects that have labels associated to them. It is not clear that there is a direct correlation between the labels of an object and the labels of its variables. Our view is that we could add an additional layer of security between objects to determine whether an object obj1 is allowed to "communicate with" another object obj2. In terms of security labels, this may be allowed if the security label of obj2 dominates that of obj!. This is independent of the information flow constraints of messages and methods. Furthermore this could be provided by the "discretionary access control layer" described earlier. Different alternatives are then possible to define the relationship between the object's label and the labels of its state variables and methods.. For instance, • The label of an object should dominate the labels of its methods • The label of an object should dominate the labels of its state variables. The model presented in this paper does not have a security label associated with an object. Classes : The next question to consider is whether one should associate security labels with classes. In this paper, we will not do so. However, it may be reasonable to allow certain security label relationships to be built into object class templates, especially when the objects themselves have security labels associated with them. For example, we may assign a set of labels to a class template, and insist that the labels of objects created from . this template must be in the set of labels assigned to the class template. In section 6 we shall consider a model in which labels are only assigned to the following entities : variables, methods and messages. When we come to considering how labels are assigned, we shall demonstrate that although it may make sense to change the labels of the variables, it does not make as much sense to change the labels associated to the methods. The labels of the methods can then be statically determined, and built in to the template.

Let us now consider in a bit more detail the interactions between the methods and the variables during system operation and clarify the type of trust involved.

12

METHOD

MONITOR

I---ivar

Local Store

D

D

!----{var

Figure 1: Method with Local Storage

5.2

Managing Method and Variable Interactions

It is necessary to consider the "implementation" of the methods of an object, with relation to the interaction between the methods and the object's state variables. The process that manages, or regulates, the interaction between the method and the state variables must be "trusted" to some degree. We shall call this process the monitor.

In some models of MLS object systems, the security labelling has been at the object level, and not the individual variable level. In our model, we separate the labelling of the methods from the labelling of the state (object's) variables. As the methods generally interact with (read or write) these variables, there must be some mechanism for assuring that all interactions are "legal", and there is not a breach of the security policy. In our model it is the monitor that performs this role. The monitor acts as a trusted run-time checker of inter and intra object communications. There are, however, two possibilities for the monitor: either (1) it manages interactions between the method and the state variables, or (2) it manages the interactions between the method and all variables that are used by the method. (In fact, we not only have to consider explicit local stores, such as assignment statements, but also implicit storage which can occur from composition of functions, such as I(g( e) ). The difference here is extremely important, as it affects the labelling of messages. In the former case, we assume that the method may have some local storage, and therefore manages its own local variables (see Figure 1). The monitor only checks that the method has read and write permission to the state variables. This is "black box" checking, and can be done statically.

In the second case, we assume that the method has no local storage, and that it is just an algorithm. Any temporary storage, or interaction with the state variables, must be done through the monitor (see Figure 2). This is a "white box" approach, and may involve runtime checking. The monitor must therefore be trusted to manage all interactions with the method and any stored data. Although this forces us to assume more trust in our monitor, it allows us to havea finer relationship between methods and messages. Consider case (1): a method can access certain state variables, which may have different security labels attached to them. As the method manages its own local storage, we cannot tell whether data assigned to variables of a higher classification is being packaged into mes-

13

I-----{var

METHOD

MONITOR I----Ivar

Figure 2: Method using Monitor for Local Storage sages of a lower classification. So if a method has access to both classified and unclassified data, then we cannot tell whether the method will send classified data in an unclassified message. All that we can say is that any message may contain classified data. We must therefore label all messages as classified. That is, we must label all messages with the classification of the method. It would be more general to say that the label of messages must dominate the label of the method (that is, messages may have labels that dominate those of the methods), as this satisfies the principle of information flow confidentiality. However, we do not allow this as it raises issues of integrity, and does not seem particularly useful. We can improve upon the above case if we know that methods cannot store information between invocations. That is, if we know that whenever a method is invoked, it initially has no (stored) information. So it cannot send information that has a level higher than the 1.u.b. of the state variables that it accesses during that particular invocation of the method. If the montior knows that a method starts with no information, and gets information from the state variables, then the monitor can set the level of any outgoing messages to be at the level of the 1.u.b. of those state variables 'used so far' by the method, but possibly less than the level of the method itself. Now let us consider case (2): here the method has no means of storing data, and so must interact with the monitor to read and write data. Clearly the monitor can check that the interactions with the state variables are valid (as in case (1)), but can also maintain labelling information of the (temporary) local variables. All assignments to local variables must be performed via the monitor. Thus the monitor can check the label associated with the value of say a state variable, and assign this label to the local variable. This then allows a method to send messages at levels that are dominated by that of the method. No information flow leakage can occur via the message, as the monitor knows the labels associated with the values in the messages and the monitor is a trusted entity. So, for example, a classified method can send an unclassified message, with the assurance that the unclassified message contains no classified information.

5.3

Setting and Changing Security Labels

We shall now look at how Iabels are assigned to variables and methods in objects, 'and how they can be altered. Along with this we shall be considering who can request the creation and alteration of security labels, and who can perform the label setting.

14

5.3.1

Setting Labels

Maintaining a consistent model, we shall only consider requests for object creation and deletion to be messages from other objects, and not add additional machinery to the model. Furthermore we shall consider creation and deletion to be managed by special "factory" objects, as described earlier.

.

Here we shall just consider the assignment of security labels at the time of object creation. We shall assume that an object cannot be partially instantiated during creation. This means that all variables of the object must be assigned values, and must have security labels associated with them. We shall therefore be assuming that the object is created atomically (there can be no interaction with the object until it has been completely created). An alternative approach is to consider creation and instantiation as separate actions. So, an object could be created, but no values (including labels) may be assigned to its variables. We do not feel that this consideration makes much difference to our understanding of the model. Let us now consider the request stage where an object wishes to create a new object and issues a request to a factory object. That is, the requesting method invokes the create method of the factory object. As the requesting object knows nothing of the internal representation (implementation) of the object, including its instance variables, all that it can do is assign levels to the data it wishes to initialise the object with. This encapsulation principle ensures that a requesting object only knows the interface of the object, and not its internals. For the purposes here, we assume that.an object may not set the labels of the methods at object creation, and also no object may change the label of a method during the lifetime of an object. The intuitive reasoning behind this assumption is that a method is essentially an algorithm (with or without local storage). As all objects are created from a given, fixed, template, then there is no way in which the algorithm (implementation of the method) may be changed - the method remains the same in all objects derived from that template. However if we were to take a stronger approach to the separation of method interface and body, then the assumption that the implementation does not change can no longer be justified. In the case of variables, however, we are continuosly changing the values assigned to the

variables. That is, we are always changing the contents of a slot, so that with the importance of the contents of the slot, we must accordingly change the security label associated with the slot. Remembering that it is the information which we are trying to protect, then it is reasonable to regrade the information stores as the information itself changes in relevance. As before, the change of levels of state variables is internal, and there may not be a simple mapping between these and the information at the object interface. Methods, on the other hand, are assigned labels not on the contents of the information which they contain, but rather on the trustworthiness of their handling of information. As . they do not change with time, so neither does their trustworthiness. Let us now consider the security label associated with the message sent by the requesting object. We have two possibilities for the label of a message, depending on the 'trustworthiness' of the monitor. Suppose we have an object A, with a method ~, and that m sends a

15

message msg requesting the creation of a new object. From the previous section, we know that the label of the message msg (invoking a 'create' method) could be at the same level as the method m (Case 1) or dominates the level of its components but dominated by the level of the method m (Case 2). For both cases, the contents ofthe message must now be considered as being at the same level as the message. The contents of a message, requesting creation of an object, contains the values that are to be assigned to the new object's (internal) variables at initialisation time, and also the labels that should be associated with these values. The create request message cannot know how the new object is to store the values, and their labels, but the association between the values and variables is managed by the factory. This message is sent to the appropriate factory object which then creates the requested object. As the values of the contents of the message are sent at the level of the message, then they must be assigned to the variables in the new object with at least this classification. In other words, the labels, sent in the contents of the message, must dominate the label of the message, for otherwise we could send a message containing classified information, to create another object with the same values assigned to similar variables, but for which we downgrade the classification. This may be checked by the factory object, or may be part of the underlying system. Such an object creation process immediately raises some questions regarding the trust of factory objects. Consider the following situation. Suppose we wish to create an object which has two variables vl .and v2, and we wish to assign labels 11 and 12 to them respectively, with 12 > 11. So, we issue the create request to the factory object with the given values. Now the security label of the factory (or of the 'create' method of the factory) cannot be 11, since it is also required to create information of label 12. However it cannot be at label 12, if it were untrusted, because it would not be able to create variables with a lower label. Therefore the create method of the factory object must be "trusted" in the mandatory security sense, Le. it is allowed to act at various security labels without violating the information flow policy. This will in turn imply that the factory object also needs to be trusted. Recall that the factory contains the method definitions for the objects, which is static throughout the lifetime of the system. It is reasonable, therefore, to trust the factory objects to faithfully create thenew objects, and to assign values and labels to the variables.

5.3.2

Changing Labels

As with the case of creating labels for a new object, we must ask some fundamental questions regarding the changing oflabels: who can ~uest changes, and who can perform the changes. Also we must ask what are the restrictions on the requestor and the performer for a valid change to occur. The first thing we should note is that labels can never be downgraded, as this immediately causes a violation in information flow. Thus all operations requesting changes to labels must request changes upward only. There may be occassion to take exception to this principle, such as when information is over classified. It may 'then be desirable to bring a trusted subject in to the model that can be responsible for such changes. This could be managed

16

for instance by using the Separation of Duty principle. Once an object has been created, it is essentially an independent entity. The only way to access the objects' variables, and consequently their associated labels, is through method invocation. We shall therefore let the object manage its own security labels. Note that from an encapsulation point of view, a user is interested not in the levels of the state variables, but rather in the levels of the (interface) data, which may not be simply related to the state variables. It is possible that any method of an object can alter the labels of each of the variables it accesses. However, this is not the most general approach, and in itself may cause problems of integrity. Therefore, for each object we shall assume there exists a method that performs the transformation of labels. The next question to ask is: what restrictions need to be imposed on the label of the method (for performing changes to the labels), and on the operation of the method? Also we need to address the question as to who may invoke the method which changes the labels. {From what we already have in our model, the label of the message requesting the change of an object variable's label must be dominated by the label of the method that performs the change. Now the method to change the label of some stored data (defined at the interface) is invoked with the name of the (interface) variable, and also with the new label. This is mapped to the internal state variables appropriately. As variables' labels should not be downgraded, the new label must dominate the current label of the variable. As the change method is always in the writing mode (and not in the reading mode), the label ofthis method should be dominated by the label of each of the object's variables whose labels are being changed. The above constraints preserve information flow security in that no sensitive information can be leaked. However, they do not place any restrictions on who (which objects' methods) are allowed to invoke this 'change label' method. We feel that this control should be specified as part of the "upper layer" access control restrictions - which would only allow certain objects (e.g. security manager objects) to invoke this particular method.

A Particular Model

6

Having considered some of the key issues and alternatives involved in the design of a multilevel information flow security model for an object system, we now propose a particular model. In this particular model we have decided upon certain properties to be satisfied by our object system, and a number of security properties that should hold within the system to implement multilevel security. The security policy is embodied in the security properties, and could be used as the basis for variants on our object model. It highlights how such a security policy affects an object model.

6.1

The Object Model Properties

1. All objects and factory objects have a unique identifier.

17

2. All methods in an object have a unique name. 3. Messaging is asynchronous message passing, with non-deterministic delay. 4. All factory objects have two methods - "create-object" and "delete-object". 5. A factory object maintains a record of the identifiers of objects it has created but not deleted (i.e. those exisiting objects). 6. Factory objects assign unique identifiers to objects that they create. 7. All objects are single threaded - only one method may be invoked on an object at a time (thus avoiding problems of deletion and change of security labels with multithreaded objects). 8. All methods have local storage. 9. Creation is via objects invoking the "create-object" method of a factory. This creation is atomic and complete (all variables and labels are assigned). The factory manages the mapping from the initial interface values and labels to the implementation (internal) values and labels. 10. Objects can only request their own deletion. To delete itself, an object must invoke the "delete-object" factory method, and then terminate itself. 11. All objects have a "Change-Label" method. These methods manage the internal mapping from the interface variables and labels to their internal representations.

6.2

Security Properties

We have divided the set of security properties into four groups: The first group is typically concerned with the properties required during system set-up. The second group deals with properties related to message passing between objects. The third group outlines the properties concerned with the operation of methods within an object. Finally the fourth group looks at modification of security labels and creation/deletion operations. Group 1 - System Set Up • The labels should be attached to variables, methods, and messages, and should form a lattice. • Methods, messages, and variables should be assigned single labels, except for factory methods. • Factory methods may have a set of labels assigned to them, Factory objects are "trusted" to work at many labels. • The labels of the method's are fixed. Assignment of labels to methods falls outside this model.

18

• The underlying inter-object communication is "trusted" not to breach the security policy. That is, it faithfully communicates the messages but performs no other actions. • The object monitor is "trusted" in that it faithfully manages the interactions between the method and the object's variables. Group 2 - Message Passing • The label of a message should be equal to the label of the method in which it originates, except if the message contains no data, in which case the label of the message is 'system-low' or 'unclassified'. • The contents of a message are considered to be at the level of the message. • The label of a message should be dominated by the label of the receiving method. • If a method ml sends a message msgl to invoke method m!, and receives message msg! on successful termination of m!, where data is exchanged in both directions, then ml and m! must be at the same label.

Group 3 - Methods • The label of a method should dominate the labels of the object's variables that the method has read access to. • The label of a method should be dominated by the labels of the object's variables that the method has write access to. • If a method is performing both reading and writing operations on a variable, then the label of the method should be equal to that of the variable.

Group 4 - Modifying Labels • The labels of the variables of a newly created object should dominate the label of the requesting message. • A message requesting the invocation of a "Change-Label" method, must contain the name of the variable (whose label is to change) and the new label; The new label must dominate the current label of that method. • The label of the "Change-Label" method must be dominated by the label of each of the object's variables.

7

Future Work

There has been a lot of developments in distributed computing, but little activity in security for such systems. So far we have considered a fine grained analysis of the mandatory information flow properties of a distributed (object) system. Some simplifications were made, and it has been recognised that additional security mechanisms, namely discretionary access control, need to be given. Here we outline some possibilities for future work.

19

7.0.1

Multi-labelled Methods

One assumption made was that methods should have a single label attached to them. This indeed gives us simplicity, but may lose us generality. An alternative is to assign a pair of labels to a method. The pair relate to the level of the outgoing messages, and the level of the incoming messages, < LOUT, LIN >. This pair of values need not necessarily be statically determined (as in the above model), but may change with time (as the state of the system changes during method execution). The reason why we may wish to consider such a pairing is that this does not force us to have two way communication between objects (methods) at a single level. Consider the following: An object A has its method rna invoked, and is executing this method. Suppose that the label pair of this method at this moment is < LAouT, LAIN >. Now, if it wishes to send a message to an object B, then the label pair represents the level of the outgoing message LAouT, and the expected level of the return message LAIN. This message invokes a method mb on B, which has a label pair < LBoUT,LBIN >, which are constraints on the method. These constraints give us a pair of conditions which allows us to determine, before fflb begins execution, whether the method can be invoked. 7.0.2

Context Dependent Label Pairs

When considering label pairs, above, we have just considered the interaction between two objects. It may be the case that the label pair of the executing method changes with time due to its context. So, we need not assume that the label pair of the method m, is the same as the label pair of its execution. However, the use of dynamic label pairs introduces further concerns for trustworthiness. If we can check the internal behaviour of the method during execution, then we can allow almost total indepedence between the pairs of labels as they change (during the method execution). This is the same for our simple model, whereby if we can monitor all storage, then the levels of outgoing messages depends only on their content, and not on what information has been read before.

If we know that the levels of instance variables are fixed, then we can statically determine the levels of the method during execution. On the other hand, if we know nothing of the internals of the method, but only know the pairs of levels at run time, then these pairs must always be non-decreasing in level during the execution of a method (to avoid possible downgrading of information within a method). 7.0.3

Classes and Inheritance

We have treated rather lightly the more complex object oriented concepts of class, subtype, and inheritance. This was more because of our wish to concentrate on the mandatory security aspects of the model, rather than because any disregard for their importance in object oriented languages. These concepts do deserve greater understanding, and a more detailed explanation.

20

Along with developing general security frameworks for object systems, it would be appropriate to examine the finer complexities of the object paradigm. The theory of inheritance and sub typing is generating much interest in the object oriented world (see [4]), and may have further implications in our MLS model. Type theory is used to reason about the interface and behaviour of objects in object oriented languages. Type checking has implications in information flow security, as we can consider security labels as types. Thus type theory gives us an expressive mechanism for checking the security types of our system both statically and dynamically.

7.0.4

Formal Specification

We have given only an informal description of a multilevel secure object model. However, we recognise the need for a more formal footing for this work, and there has already been some effort in this direction. Our intention is to formalise both the object model, so as to get a better understanding of the object concepts, and the security model iself. We are not trying to specify a partiduar system, but rather a framework from which particular systems can be built. That is, we do not want to describe some object system, but instead describe the underlying object concepts and object interactions. So, to formalise our concepts we need a language that allows us to make general statements about a system. An assertionallanguage, such as Z, would be sufficient for describing basic object systems, the association of labels to components of the system, and for describing constraints on the behaviour of such systems. Other approaches will also be considered.

7.0.5

Discretionary Security Mechanisms

This paper has dealt with mandatory security mechanisms in a distributed, object oriented system. Clearly this model is not sufficient in itself. We need, in addition, authentication and access control mechanisms. The multilevel security model gives us necessary conditions for maintaining authorised information flow. Access control mechanisms should enhance this model by adding additional constraints on the rights of users (objects, or methods) to access information, or invoke methods. Additionally we need to look at the distribution of rights, such as passing rights for proxy, changing rights, and separation of duty for managing rights. The access control model can be seen as another layer of security placed on top of our multilevel security model. We hope to provide, in a forthcomming paper, both a general discussion of access control in a distributed object system, and a particular model based on this discussion. The work can be seen as a complement to this present paper.

8

Acknowledgments

The authors would like to thank their colleague Phillip Allen for his energetic reviewing of this paper, for pointing out our object-oriented impurities, and for suggesting alternative viewpoints.

21

References [1] P. America, A Behavioural Approach to Subtyping in Object Oriented Programming Languages, in Proceedings of REX/FOOL, Foundations of Object-Oriented Languages, June 1990. [2] D.E. Bell and L.J. LaPadula, "Secure Computer Systems: Unified Exposition and Multics Interpretations", Tech.Report MTR-2997, Mitre Corp.,US, 1976. [3] S.A. Black, "Objects and LOTOS", Proceedings of FORTE'89, the Second International Conference on Formal Description Techniques for Distributed Systems and Communications Protocols, 1989. [4] W.R. Cook, W.L. Hill, P.S. Canning, Inheritance is Not Subtyping, Conference Record of the Seventeenth Annual ACM Symposium on Principles of Programming Languages, January 17-19, 1990. [5] G.F. Coulouris and J. Dollimore, "Distributed Systems: concepts and design", AddisonWesley, 1988.

[6] B.J. Cox, "Object-Oriented Programming: An Evolutionary Change in Programming Technology", Addison-Wesley, 1986. [7] D.E. Denning, "Cryptography and Data Security", Addison-Wesley, reading, MA, 1982. [8] A. Goldberg and D. Robson, "SMALLTALK-80: The Language and Its Implementation", Addison-Wesley, Reading, MA, 1983. [9] T.F. Keefe, W.T. Tsal and M.B. Thurasingham, "SODA: A Secure Object-Oriented Database System", Computers and Security, Vo1.8, 1989, pp 517-533.

[10] T.F. Keefe, W.T. Tsal and M.B. Thurasingham, "A Multilevel Security Model for Object-Oriented Systems", Proc. 11th National Security Conference, Oct.1988.

[11] P.J. Leach et al, "The architecture of an integrated local network, IEEE Journal on Selected Areas in Communications, SAC-I, 5, pp. 842-56. [12] B. Meyer, "Object-Oriented Software Construction, Prentice-Hall International, 1988. [13] J.G. Mitchell and J. Dion, A comparison of two network-based file servers", Communications of the ACM, 25, 4, pp. 233-45. [14] R.M. Needham. and A.J. Herbert, "The Cambridge Distributed Computing System, Addison-Wesley, 1982. [15] M. Stefik and D.G. Bobrow, "Object-Oriented programming: Themes and Variations", AI Magazine, Vo1.6, Part 4, 1986, pp4o-62.

22