F.f..- HEWLETTa:~ PACKARD

A Multilevel Security Model for aDistributed Object-Oriented System

Stewart Black, Vijay VaradharajanNetworks and Communications LaboratoryHP Laboratories BristolHPL-90-74June, 1990

multilevel security,information flow,object model

It often suggested that distributed computing willbe the major trend in computer systems duringthe next decade. However, distributed systemsare vulnerable to a number of security attacks. Inthis paper we look at the security problems ofobject-based distributed systems, and propose amodel based on labeling for multilevel security.The purpose of this model is to preserve theinformation flow security in a distributedobject-oriented system.

We consider the basic concepts of the objectparadigm, and also the security threats to suchsystems. We postulate various modelingpossibilities, and produce a specific set of securityproperties which describe a multilevel secureobject model. This particular model should not beconsidered as a panacea, but rather shoulddemonstrate how the various modeling decisionsare reflected in an actual model. We concludewith a discussion of possible avenues of futureresearch.

© Copyright Hewlett-Packard. Company 1990

Internal Accession Date Only

1 Summary

This paper discusses the issues in multilevel secure object systems. In particular, we lookat multilevel information flow security models for an object-oriented system, based on theuse of security labels. Most of the existing work to date has been based on assigning labelsto the objects, and is concerned with database systems [9], [10]. However, we consider moregeneral object syst~ms, existing in a distributed environment. Our approach takes a finegrained 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 theimplications for information flow security. As we consider objects in fine grain, and also ina distributed environment, we have information flow at the inter and intra object level. Atthe inter object level, objects are communicating via asynchronous message passing. At theintra object level, methods are reading and writing instance variables.

With this fine grained view of labelling, we ask questions about the relationship betweenlabels of variables, methods, and messages. This relationship depends upon how muchcontrol we can have in checking during run-time that the security constraints are beingsatisfied. We assume that the object management and run-time checking is done by trustedprocesses, 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 towardsadditional models, such as discretionary access control.

The particular information flow security model that we have considered here is prima.rilyconcerned with the mandatory security aspects. In addition to this, it is necessary toconsider the discretionary security issues. In an object-oriented system, the natural pointof control for discretionary access is the reception of a message at an object. The messageshould be refused if it comes from an object (or acting behalf of an object) who is notauthorized to send the given message to that object. In such a scenario, we need to considerthe issues such as how are authorizations expressed, stored and propagated and how arethe discretionary controls enforced? We envisage such a discretionary security layer to bespecified "on top" of the proposed information flow security model.

2 Introduction

2.1 Background

The last ten years has seen the rapid growth in networked computer systems. Networksallow a number of computers to electronically exchange information with each other. Thishas presented a great opportunity for the sharing of computer resources (such as processingpower, storage, printing), and we are 'now beginning to see the exploitation of this oppor­tunity. The phrase. 'distributed computing' is used to describe the potential that a networkof computer systems can offer.

Over the years there has been a great deal of interest in distributed compu~ing, but it is

2

only now that we are beginning to see the commercial possibility of this technology. Therehas been a considerable amount of effort in the area of distributed data and files, with theXerox 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 thedistributed storage and maintenance of information, and the distributed processing of theinformation that characterises distributed systems.

Another, independent, technology has developed at the same time, namely that of 'object­oriented programming' ([15], [12], [6]). Essentially object oriented programming evolvedfrom a programming design methodology, with "clean" and minimal interfaces betweenprogramme modules. Unlike the more familiar programming methodologies based uponfunctional design, the object-oriented approach is based .on the data. The modules of thesystem are not functions, but data and operations specific to that data. This modularitywas also driven by another concern - re-use of programme components. A number ofprogramming languages evolved embodying these concepts, most notably Smalltalk [8]. Theobject-oriented programming approach is a step forward in software quality and re-use, andis gaining in popularity.

One of the advantages most commonly cited for adopting the object approach is that it isa more "natural" way of capturing real-world situations within a programme. It is easy tosee that the object concepts, of self-contained, encapsulated data entities communicatingwith other such entities, are easily paralleled within real distributed systems.

The advantages of distributed computing are well publicised. However, there is a price topay 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 youdo not have complete control on the management of your information so that it may besubject to alteration, deletion, replication, and unauthorised disclosure. Hence distributedsystems are more readily prone to security threats, and therefore demand a much greaterneed 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 infor­mation (or "leaks" it) to unauthorised entities. One can overcome this "leakage problem"by enforcing suitable flow policies which restrict the flow of information between differentsystem entities. Typically in the lattice model of information flow [7], the system entitiesare assigned "security labels" and the control of flow of information between two entitiesis regulated using these security labels. These labels signify different levels of sensitivityassociated with the entities. In this paper, we will be addressing the key issues relatedto the development of information flow security policies for a distributed object orientedsystem 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 basicconcepts of objects, and then shall consider mere complex, and realistic problems of ob­jects, such as object creation, .deletion , and design issues such as inheritance. Section 4considers 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 modelbased on security labels in Section 5. In this section, we begin by considering the potentialthreats to a distributed object system. Then we consider the granularity to which securitylabels should be assigned to components of the system. Also we look at the granularity ofthe underlying object manager (monitor), and how security labels are assigned and changedduring the system lifetime.

Section 6 proposes a particular model and describes its security properties, so as to exem­plify the approach to formalising our model. There is then a discussion of possible futuredevelopment of this work in Section 7.

3 Object System

In this section we shall briefly describe object models of different complexity. It is not ourintention 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 relatesto 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 interactwith each other?'. In solving these questions we do not consider more detailed questionssuch 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'svariables, 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 withone another by sending messages to each other's interfaces (so no shared variables). Theinterface to the method is all that a user of the object is concerned with. The messagestructure relates to the method interface, and not necessarily to the method internals, orimplementation. In our model it is important to notice that there are essentially two kindsof messages, namely those requesting the invocaiion of a method (the "call"), and thosereturning the result ofthe method invocation (the "return"). The reason that we distinguishthe 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 communicatingover 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 asshared, atomic interactions. (Note that there are several definitions of synchrony. In thisinstance 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 toosimplistic for realistic situations. Most applications require the possibility of the creationand deletion of objects within the system.

Let us consider a system (of objects) that contains information on employees. There areobjects in the system that represent employees, and each employee object contains infor­mation on the employee, such as name, address, and salary. Each employee object also hasmethods (operations) for accessing (reading/writing) the information on each employee. Insuch 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 consideringdynamic systems of objects. If we wish to create new objects, then it is necessary to saywhat kinds of objects we want in terms of what information they should contain, whatoperations they should have, and also what their implementation is (though this last pointmay not be of concern to other objects in the system). The concept of template allows us tomake statements such as "create me an object with the state variables and methods of thistemplate, and assign these values to the variables of the object", or more briefly " createme one of those". The template describes the implementation, or realisation of the requiredobject. It combines the user's view of the object (the interfaces) with the internals (statevariables, and method implementations). In other words, a class template is a. templatefrom which a number of similar objects can be constructed.

A template can be re-used for constructing objects with similar features (such as the typesof the state variables, and the methods). When requesting the creation of an object, theclass 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, anda 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. Inthe example above of a company's personnel information system, we have an object for eachemployee. We use a template for employee objects, so that each employee object is just aninstance of the employee template. The class of employee objects is the set of objects thatare 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 somedecisions as to how creation and deletion should be handled, who should be allowed tocreate and delete objects, and whether there are any relationships between the creating andcreated objects. In the previous section we have considered the use of templates for creatingobjects. 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 orientedprogramming languages is to use the concept of factory ([12]). A factory object is a specialkind of object that represents a manager of objects of a specific class template. In thecreation and deletion of objects, the messaging concept is maintained. A factory objecthas methods for creating and deleting objects of a certain class, and manages the creationand deletion of these objects (as well as identification). Going back to the example of thepersonnel system, we would have an employee factory object. Every time we wanted to adda new employee object, we would send a 'create' message to invoke the 'create' method ofthe 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 userto the newly created object's internal representation. The user does not need to know howthe information is stored in the new object, and neither how it is implemented. The userdoes expect the new object to .have a well-defined interface, and that the factory faithfullyimplements the behaviour of the required object.

Deletion of objects is also an important issue. There are a number of possibilities fordeletion, such as deletion via factory objects, allowing only the object itself to request itsdeletion, 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 importantfrom a modelling point of view, as an object can be ignored if it is no longer used. Withinreal implementations we do have finite resources, and so memory management, and objectdeletion, are important.

Re-usability is another advantage of the object oriented approach. Above we have discussedthe re-use of the template to create several objects of the same kind. This is both a designissue and a (dynamic) run-time issue. The concept of re-usabillty can be applied at design­time, with the concept of inheritance. This is an extremely important concept in objectoriented 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 rathersuperficially. For our purposes, inheritance is a mechanism for constructing templates fromexisting templates. That is, to create a new template we can 'inherit' the description ofstate 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 notaffect our general object model, though it does open some interesting questions regardingtrust of inherited templates, and additionally some security considerations on implementingmechanisms for inheritance.

6

4 Security Policy

A security policy is a description of the needs and requirements of a system to compensatefor, or protect against, various threats to the system. This is a high level declarativedescription reflecting the security problems faced by the system.A security model is a representation of the security policy and deals with the securityproperties (such as rules and constraints) of the system. The security model is abstract andgeneric 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 adistributed 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 objectsystem. With each possible threat is identified a class of policies and mechanisms that areintended to prevent the threats from occurring.

1. Unauthorized Access to Objects: This class of threats is essentially concerned withan object accessing another object (e.g. invoking a method in another object) forwhich it has no authorization. It also includes threats against propagation of autho­rizations. To counteract such threats in anobject-oriented system, the natural pointof control is the reception of the message at an object. For instance, one can proposea 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 methodcall from a given object should be granted or not. We may either state who may beallowed to invoke a method, state who may not be able to invoke the method, or statethat only objects with certain properties (attributes) may invoke the method. Thenwe can develop suitable mechanisms to prevent misuse in access control informationpropagation. Such policies form part of a discretionary access control model for anobject-oriented system and they will be addressed in a separate paper.

2. Unauthorized Information Flow: By information flow control, we mean that theflow of information between two entities must be suitably restricted not to violate aprescribed set of flow policies. For instance, when information is transferred betweenobjects during messaging, we wish to ensure that the flow of information does notcontravene our flow policy. This paper is primarily concerned with such informationflow security policies for an object oriented system. Such an information flow modeladdresses the mandatory security issues of an object-oriented system. In fact, weview 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 anobject 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 itclaims to be. We do not. want to allow objects to masquerade as other objects byfalsifying their identifiers. Policies and mechanisms to implement such guarantees fallwithin the notion of authentication.

7

4. Data Protection: Finally we need to protect the communications themselves. Thereare a number of possible threats to communication which are the domain of commu­nications security. The main approach to providing communications security employscryptographic 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 thedenial of service. Informally, the denial of service is said to occur when an object makesa specified service unavailable to another otherwise-authorized object for a period of timethat 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 incorporatinginformation flow security properties, it will be useful to briefly describe the concept ofmultilevel security and some associated teminology.

4.2 Multilevel Security

The information handled in multi-user systems typically has different levels of sensitivityassociated with it. Some information is likely to be more important than others. Thereforeit is necessary to devise some means whereby only some users of the system have access tosuch information. Again going back to the example of the personnel system, an employee'saddress may not be considered sensitive information, so all users of the system could ac­cess this information. However, their salary may be considered confidential, so that onlyan employee, her/his managers, and the personnel department, may have access to thatinformation. "

So the purpose of multilevel security is to avoid the unauthorised disclosure of certaininformation to certain "untrusted" users. One mechanism for implementing this policy isby assigning security labels to the information and users of the system. The label representsthe level of sensitivity of the information, or the level of sensitivity to which a user is allowedaccess. This prevents users accessing information with a security label for which they arenot cleared.

The case of military information systems is typical of the restrictions placed on the informa­tion 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 aclearance. So a user may only view some information if its clearance dominates (see Sec­tion 3.2.1) the classification of the information. For instance, a General, who has clearanceof Top Secret, may access all information of the system, whereas an Engineer, who hasConfidential clearance can view only Unclassified and Confidential information, but notinformation classified as Secret or Top Secret.

The most well-known multilevel security model is the Bell-Laf'adula model [2]. Here asystem is viewed as a collection of "subjects" (processes, users) and "objects" (data) 1. Eachsubject and object is assigned a security label. The behaviour of the system is representedby a set of system states, state transitions, and an initial state. The significant operationsallowed in this model include read, append, uecute and read-write. A ~ta.te defines the accessthat subjects currently have on" objects, and the current security labels associated with the

lIn this section, the term "objects" are used in this t~aditional8enseand not in the object-oriented sense

8

subjects and the objects. The Be1l-LaPadula model defines the properties for a state to besecure and suggests the kind of restrictions needed on these operations to preserve thesesecurity properties.

Modelling information flow is relatively uncomplicated compared with the Bell-LaPadulamodel. Instead of a series of conditions and properties to be maintained, there is the singlerequirement 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 allowedto access information whose level of sensitivity is greater than that of the user. Whenconsidering the main operations of reading and writing data, this principle is manifestedas "no read up, no write down". So, a user can only read (receive) information of a lowerclearance 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 thelabel of the information generated by any binary operation on information with twolabels;

• a flow relation that, for any pair of security labels, determines whether information isallowed to flow from one to the other.

One may distinguish between an accesss policy and an information flow policy in the fol­lowing way: The access policy specifies the rights that subjects have to objects whereas theinformation flow policy specifies the labels of information that can be contained in objectsand 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 restrictthe flow of information (and hence the information that can be contained in a particularobject). Conversely, restrictions on flow will have an effect on what access rights a givensubject can exercise for a given object.

4.3 Notation

Before we discuss some of the issues related to the design of an information flow securitymodel for an object oriented system, it will be useful to give here the common definitionof the relation "dominate" on the set of security labels - as this relation will be usedthoroughout 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 alwayspossible to compare two security labels using the "dominate" relationship. In this case, theyare said to be incomparable. In this paper, we will further assume that the set of securitylabels is a lattice with respect to the partial ordering ~. That is given any pair of elementssl1 and sl2 :

9

• the set of all security labels dominated by both sl1 and sl2 is non-empty and containsa 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 containsa 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 theentities that make up the abstract system. As we are considering a multilevel security modelproviding information flow security, we then need to consider how we can associate securitylabels to the system entities. This involves considering the different levels of granularitythat can be adopted. Following on from this, we need to develop suitable schemes to ensurethat 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 betrusted. Finally we shall look at the problem of assigning and altering the security labelsof 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 thatare relevant from the point of view of assigning security labels include: variables, meth­ods, messages, objects and classes. Each object consists of data variables, each of whichcould conceivably be assigned a different security label, and operations which may alter thevariables' values (and possibly their security labels). The question of where to check thesecurity 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 ofinformation, that should be assigned security labels. We take the view here that it is thecontainers ('slots' or 'variables') that should be assigned labels and that the label of thecontainer reflects the sensitivity of its information content. Hence controls that deny accessto information are based on the. labels of the containers. For example, what is the labelthat should be assigned to the integer 1001 Clearly the answer depends on the context, orwhat it is supposed to represent. AB all values are contained in slots, then it is the slotthat models the real-world entity. Thus it is the 'salary' slot in the personnel file that is ofsemantic relevance, and not the integer value that is contained in the slot. However, theremay be a relationship between the range of values that may be assigned to the slot, andthe labels that may be attached to that slot. We may sometimes talk about the label of avalue 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 followingissues:

• What are the relationships between the method and variable labels?

• What is the relationship between the message label and the data contained within themessage?

• 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 andusers is to avoid the unauthorised disclosure of information. Therefore it is the data which issensitive, and must only be disclosed to select users. In our case the data is that associatedwith 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 asgeneric 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 casewe shall use in most of our discussion. However, in section 7 we consider alternatives tothis approach. With a single level, we need the following constraints: (1) the level of themethod should dominate the levels of all the state variables that it can read, and (2) thelevel of the method is dominated by the levels of all the state variables that it can writeto. These constraints can be considered also in terms of the input and output levels of amethod, 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 ofthe objects. Remembering that information should only be written up and read down, andassuming 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 thelabel 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 labelof 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 shouldbe equal to the label of the variable.

Messages Communication via messaging is the most basic level of information flow. Itis essential that the message is suitably labelled to avoid the unauthorised disclosure ofits contents. As messages are essentially 'one off', we need only assign a single level to amessage. In this paper we use the term 'message'· to refer to both the method invocationand the return message (on completion of the invoked method). Using the write up, readdown principle, we can deduce the following:

11

• When data is passed between objects during messaging, the label of the messageshould 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 ofB'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 originatingthe message is discussed in the next section.

Objects: So far we have not considered the association between the labels of an object'svariables, and the label of that object. In most proposed multilevel security models (suchas [9], [10]) the lowest level of granularity is that of the object. That is, in these models itis only the objects that have labels associated to them. It is not clear that there is a directcorrelation between the labels of an object and the labels of its variables. Our view is thatwe could add an additional layer of security between objects to determine whether an objectobj1 is allowed to "communicate with" another object obj2. In terms of security labels, thismay be allowed if the security label of obj2 dominates that of obj!. This is independentof the information flow constraints of messages and methods. Furthermore this could beprovided by the "discretionary access control layer" described earlier.

Different alternatives are then possible to define the relationship between the object's labeland 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 labelswith classes. In this paper, we will not do so. However, it may be reasonable to allowcertain security label relationships to be built into object class templates, especially whenthe objects themselves have security labels associated with them. For example, we mayassign a set of labels to a class template, and insist that the labels of objects created fromthis 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 followingentities : variables, methods and messages. When we come to considering how labels areassigned, we shall demonstrate that although it may make sense to change the labels of thevariables, 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 thevariables during system operation and clarify the type of trust involved.

12

METHOD

Local StoreD D

MONITOR I---ivar

!----{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 relationto the interaction between the methods and the object's state variables. The process thatmanages, 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 methodsfrom the labelling of the state (object's) variables. As the methods generally interactwith (read or write) these variables, there must be some mechanism for assuring that allinteractions are "legal", and there is not a breach of the security policy. In our model itis the monitor that performs this role. The monitor acts as a trusted run-time checker ofinter and intra object communications.

There are, however, two possibilities for the monitor: either (1) it manages interactionsbetween the method and the state variables, or (2) it manages the interactions betweenthe method and all variables that are used by the method. (In fact, we not only have toconsider explicit local stores, such as assignment statements, but also implicit storage whichcan occur from composition of functions, such as I(g(e) ).The difference here is extremely important, as it affects the labelling of messages. In theformer case, we assume that the method may have some local storage, and therefore managesits own local variables (see Figure 1). The monitor only checks that the method has readand write permission to the state variables. This is "black box" checking, and can be donestatically.

In the second case, we assume that the method has no local storage, and that it is just analgorithm. Any temporary storage, or interaction with the state variables, must be donethrough the monitor (see Figure 2). This is a "white box" approach, and may involve run­time checking. The monitor must therefore be trusted to manage all interactions with themethod 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 differentsecurity labels attached to them. As the method manages its own local storage, we cannottell whether data assigned to variables of a higher classification is being packaged into mes-

13

METHOD MONITORI-----{var

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 unclassifieddata, then we cannot tell whether the method will send classified data in an unclassifiedmessage. All that we can say is that any message may contain classified data. We musttherefore label all messages as classified. That is, we must label all messages with the clas­sification of the method. It would be more general to say that the label of messages mustdominate the label of the method (that is, messages may have labels that dominate thoseof 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 informationbetween invocations. That is, if we know that whenever a method is invoked, it initiallyhas no (stored) information. So it cannot send information that has a level higher than the1.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 fromthe state variables, then the monitor can set the level of any outgoing messages to be atthe level of the 1.u.b. of those state variables 'used so far' by the method, but possibly lessthan the level of the method itself.

Now let us consider case (2): here the method has no means of storing data, and so mustinteract with the monitor to read and write data. Clearly the monitor can check that theinteractions with the state variables are valid (as in case (1)), but can also maintain labellinginformation of the (temporary) local variables. All assignments to local variables must beperformed via the monitor. Thus the monitor can check the label associated with the valueof say a state variable, and assign this label to the local variable. This then allows a methodto send messages at levels that are dominated by that of the method. No information flowleakage can occur via the message, as the monitor knows the labels associated with thevalues in the messages and the monitor is a trusted entity. So, for example, a classifiedmethod can send an unclassified message, with the assurance that the unclassified messagecontains 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 howthey can be altered. Along with this we shall be considering who can request the creationand 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 anddeletion 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. Thismeans that all variables of the object must be assigned values, and must have security labelsassociated 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). Analternative approach is to consider creation and instantiation as separate actions. So, anobject 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 themodel.

Let us now consider the request stage where an object wishes to create a new object andissues a request to a factory object. That is, the requesting method invokes the createmethod of the factory object. As the requesting object knows nothing of the internalrepresentation (implementation) of the object, including its instance variables, all that itcan do is assign levels to the data it wishes to initialise the object with. This encapsulationprinciple ensures that a requesting object only knows the interface of the object, and notits internals.

For the purposes here, we assume that.an object may not set the labels of the methods atobject creation, and also no object may change the label of a method during the lifetime ofan object. The intuitive reasoning behind this assumption is that a method is essentiallyan 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 andbody, then the assumption that the implementation does not change can no longer bejustified.

In the case of variables, however, we are continuosly changing the values assigned to thevariables. That is, we are always changing the contents of a slot, so that with the importanceof the contents of the slot, we must accordingly change the security label associated withthe slot. Remembering that it is the information which we are trying to protect, then it isreasonable 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 simplemapping between these and the information at the object interface.

Methods, on the other hand, are assigned labels not on the contents of the informationwhich they contain, but rather on the trustworthiness of their handling of information. Asthey do not change with time, so neither does their trustworthiness. .

Let us now consider the security label associated with the message sent by the requestingobject. We have two possibilities for the label of a message, depending on the 'trustworthi­ness' 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 knowthat the label of the message msg (invoking a 'create' method) could be at the same levelas the method m (Case 1) or dominates the level of its components but dominated by thelevel of the method m (Case 2). For both cases, the contents ofthe message must now beconsidered as being at the same level as the message.

The contents of a message, requesting creation of an object, contains the values that areto be assigned to the new object's (internal) variables at initialisation time, and also thelabels that should be associated with these values. The create request message cannot knowhow the new object is to store the values, and their labels, but the association between thevalues and variables is managed by the factory. This message is sent to the appropriatefactory object which then creates the requested object. As the values of the contents of themessage are sent at the level of the message, then they must be assigned to the variablesin the new object with at least this classification. In other words, the labels, sent in thecontents of the message, must dominate the label of the message, for otherwise we couldsend a message containing classified information, to create another object with the samevalues assigned to similar variables, but for which we downgrade the classification. Thismay 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 offactory objects. Consider the following situation.

Suppose we wish to create an object which has two variables vl .and v2, and we wish toassign labels 11 and 12 to them respectively, with 12 > 11. So, we issue the create requestto 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 informationof label 12. However it cannot be at label 12, if it were untrusted, because it would not beable to create variables with a lower label.

Therefore the create method of the factory object must be "trusted" in the mandatorysecurity sense, Le. it is allowed to act at various security labels without violating theinformation flow policy. This will in turn imply that the factory object also needs to betrusted. Recall that the factory contains the method definitions for the objects, which isstatic throughout the lifetime of the system. It is reasonable, therefore, to trust the factoryobjects 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 questionsregarding 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 validchange to occur.

The first thing we should note is that labels can never be downgraded, as this immediatelycauses a violation in information flow. Thus all operations requesting changes to labels mustrequest 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 trustedsubject 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 toaccess the objects' variables, and consequently their associated labels, is through methodinvocation. We shall therefore let the object manage its own security labels. Note that froman 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 thestate variables. It is possible that any method of an object can alter the labels of eachof the variables it accesses. However, this is not the most general approach, and in itselfmay cause problems of integrity. Therefore, for each object we shall assume there exists amethod 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 needto 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 changeof an object variable's label must be dominated by the label of the method that performsthe change.

Now the method to change the label of some stored data (defined at the interface) is invokedwith the name of the (interface) variable, and also with the new label. This is mapped tothe 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 isalways in the writing mode (and not in the reading mode), the label ofthis method shouldbe 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 canbe leaked. However, they do not place any restrictions on who (which objects' methods) areallowed to invoke this 'change label' method. We feel that this control should be specifiedas part of the "upper layer" access control restrictions - which would only allow certainobjects (e.g. security manager objects) to invoke this particular method.

6 A Particular Model

Having considered some of the key issues and alternatives involved in the design of a mul­tilevel information flow security model for an object system, we now propose a particularmodel. In this particular model we have decided upon certain properties to be satisfied byour object system, and a number of security properties that should hold within the systemto 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 asecurity 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 notdeleted (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 ata time (thus avoiding problems of deletion and change of security labels with multi­threaded objects).

8. All methods have local storage.

9. Creation is via objects invoking the "create-object" method of a factory. This creationis atomic and complete (all variables and labels are assigned). The factory manages themapping 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 invokethe "delete-object" factory method, and then terminate itself.

11. All objects have a "Change-Label" method. These methods manage the internalmapping 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 typicallyconcerned with the properties required during system set-up. The second group dealswith properties related to message passing between objects. The third group outlines theproperties concerned with the operation of methods within an object. Finally the fourthgroup 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 forma lattice.

• Methods, messages, and variables should be assigned single labels, except for factorymethods.

• 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 outsidethis model.

18

• The underlying inter-object communication is "trusted" not to breach the securitypolicy. That is, it faithfully communicates the messages but performs no other actions.

• The object monitor is "trusted" in that it faithfully manages the interactions betweenthe 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 messagemsg! 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 themethod has read access to.

• The label of a method should be dominated by the labels of the object's variablesthat the method has write access to.

• If a method is performing both reading and writing operations on a variable, then thelabel 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 therequesting message.

• A message requesting the invocation of a "Change-Label" method, must contain thename of the variable (whose label is to change) and the new label; The new labelmust dominate the current label of that method.

• The label of the "Change-Label" method must be dominated by the label of each ofthe object's variables.

7 Future Work

There has been a lot of developments in distributed computing, but little activity in securityfor such systems. So far we have considered a fine grained analysis of the mandatoryinformation flow properties of a distributed (object) system. Some simplifications weremade, and it has been recognised that additional security mechanisms, namely discretionaryaccess 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. Thisindeed gives us simplicity, but may lose us generality. An alternative is to assign a pair oflabels to a method. The pair relate to the level of the outgoing messages, and the level of theincoming messages, < LOUT, LIN >. This pair of values need not necessarily be staticallydetermined (as in the above model), but may change with time (as the state of the systemchanges during method execution). The reason why we may wish to consider such a pairingis 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 thismethod. 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 levelof the outgoing message LAouT, and the expected level of the return message LAIN. Thismessage invokes a method mb on B, which has a label pair < LBoUT,LBIN >, which areconstraints on the method. These constraints give us a pair of conditions which allows usto 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 twoobjects. It may be the case that the label pair of the executing method changes with timedue to its context. So, we need not assume that the label pair of the method m, is the sameas the label pair of its execution.

However, the use of dynamic label pairs introduces further concerns for trustworthiness. Ifwe can check the internal behaviour of the method during execution, then we can allowalmost total indepedence between the pairs of labels as they change (during the method ex­ecution). This is the same for our simple model, whereby if we can monitor all storage, thenthe levels of outgoing messages depends only on their content, and not on what informationhas been read before.

If we know that the levels of instance variables are fixed, then we can statically determinethe levels of the method during execution. On the other hand, if we know nothing of theinternals of the method, but only know the pairs of levels at run time, then these pairsmust always be non-decreasing in level during the execution of a method (to avoid possibledowngrading 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 mandatorysecurity aspects of the model, rather than because any disregard for their importance inobject oriented languages. These concepts do deserve greater understanding, and a moredetailed explanation.

20

Along with developing general security frameworks for object systems, it would be appro­priate to examine the finer complexities of the object paradigm. The theory of inheritanceand subtyping is generating much interest in the object oriented world (see [4]), and mayhave further implications in our MLS model.

Type theory is used to reason about the interface and behaviour of objects in object orientedlanguages. Type checking has implications in information flow security, as we can considersecurity labels as types. Thus type theory gives us an expressive mechanism for checkingthe 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 beensome effort in this direction. Our intention is to formalise both the object model, so as toget 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 par­ticular systems can be built. That is, we do not want to describe some object system, butinstead describe the underlying object concepts and object interactions. So, to formaliseour 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 thebehaviour 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 orientedsystem. Clearly this model is not sufficient in itself. We need, in addition, authenticationand access control mechanisms.

The multilevel security model gives us necessary conditions for maintaining authorised in­formation flow. Access control mechanisms should enhance this model by adding additionalconstraints on the rights of users (objects, or methods) to access information, or invokemethods. Additionally we need to look at the distribution of rights, such as passing rightsfor 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 ourmultilevel security model. We hope to provide, in a forthcomming paper, both a generaldiscussion of access control in a distributed object system, and a particular model based onthis 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 ofthis paper, for pointing out our object-oriented impurities, and for suggesting alternativeviewpoints.

21

References

[1] P. America, A Behavioural Approach to Subtyping in Object Oriented ProgrammingLanguages, 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 andMultics Interpretations", Tech.Report MTR-2997, Mitre Corp.,US, 1976.

[3] S.A. Black, "Objects and LOTOS", Proceedings of FORTE'89, the Second InternationalConference on Formal Description Techniques for Distributed Systems and Communi­cations Protocols, 1989.

[4] W.R. Cook, W.L. Hill, P.S. Canning, Inheritance is Not Subtyping, Conference Recordof 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", Addison­Wesley, 1988.

[6] B.J. Cox, "Object-Oriented Programming: An Evolutionary Change in ProgrammingTechnology", 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 Implementa­tion", Addison-Wesley, Reading, MA, 1983.

[9] T.F. Keefe, W.T. Tsal and M.B. Thurasingham, "SODA: A Secure Object-OrientedDatabase 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 forObject-Oriented Systems", Proc. 11th National Security Conference, Oct.1988.

[11] P.J. Leach et al, "The architecture of an integrated local network, IEEE Journal onSelected 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", Commu­nications 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