Miro : Visual Specification of Security

Miro is a set of languages and tools that support visual specification of file system security. We describe two visual languages: the instance language which allows specification of file system access, and the constraint language which allows specification of security policies. We present the syntax and semantics of these languages, and discuss some novel algorithms that efficiently check for properties, e.g., ambiguity, of instance pictures. We also describe the implementation of our tools and give examples of how the languages can be applied to real security specification problems. This research was sponsored by the Defense Advanced Research Projects Agency under Contract No. F33615-87-C-1499. Additional support for J. M. Wing was provided in part by the National Science Foun dation under grant CCll-8620027 and for J. D. Tygar under a National Science Foundation Presidential Young Investigator Award, Contract No. CCR-8858087. M. Maimone (under contract N00014-88-K-0641) and A. Moormann Zaremski are also supported by fellowships from the Office of Naval Research. The views and conclusions contained in this paper are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency, the National Science Foundation or the US Government.

Alice and Bob. The containment and overlap relationships between the world, groups, and users indicate that all users are in the world, and users can be members of more than one group. The right-hand box denotes Alice's mail file. The arrows indicate that Alice, and no other user, has read access to her mail file That is, the direct positive arrow from Alice overrides the negative arrow from World.
The access matrix (and hence the instance language) provides the ability to represent all possible security configurations. A major challenge for a security specification scheme is to restrict the set of possible configurations to only those that are realizable and acceptable.
Sin:e an operating system can only support certain configurations, some access matrices must be disallowed. For example, in Unix, a configuration in which one group of users has permission to read a file and a second group of users has permission to write that file cannot be realized (unless one group is either the set of all users or the singleton set of the file s owner) [RT87]. Other access matrices must not be allowed because specific security policies may make some situations unacceptable. For example, in the military Bell-LaPadula security model [BL73,Dep85], users and files in the operating system are assigned linear security levels (i.e., top secret, secret, not secret); it is only acceptable for users to write to files at their security level or higher and to read files at their level or lower.
The constraint language provides the specifier with a visual way to describe realizable and acceptable configurations by limiting the set of "legal'' instance pictures. A constraint picture specifies a (possibly infinite) set of instance pictures. If a given instance picture is an element of the set of instance pictures defined by a constraint picture, we say that the instance picture matches the constraint or that it is legal with respect to that constraint picture. Different sets of constraints describe different security configurations. Like the instance language, the constraint language also consists of boxes and arrows, but here the objects have different meanings. In a constraint picture, a box is labeled with an expression that defines a set of instance boxes. For example, in Figure 2, the left-hand box refers to the set of instance boxes of type User.

Syntax and Semantics
An instance picture is formed from a set of typed objects, each of which is an optionally labeled box or arrow.
Boxes represent individual users and files or collections of users or files; arrows represent access rights. A box that represents a single process or file is atomic and contains no other boxes. Boxes may be nested to indicate groupings of users or files; boxes may also overlap. Arrows can be positive or negative, representing the granting or denial of access rights. Well-formedness conditions restrict the domain of syntactically legal pictures: one condition is that arrows be attached at both ends; another is that all arrows must start from a user box and end at a file box.  Recall that the interpretation of an instance picture in the security domain is an access matrix. 1 access matrix for the instance picture of Figure 3 is given in Table 1. Any relation not specified by explicit arrow in an instance picture is denied by default. So the negative arrow in the Figure 3 is strictly necessary, but it is good "visual programming style" to make the absence of read rights explicit more formal definition of the instance language's syntax and semantics appears in the appendix.

Ambiguity
The presence of negative arrows in the language adds some non-triviality to the semantics, because pictures with ambiguous interpretations can be constructed. Figure 4 shows an example of such a picture Is Bob a special user who has access to all programs in usr. including admin° Or are no users (including Bob) allowed access to the admin directory 9 Either interpretation seems valid; therefore, we say this picture is ambiguous.
f World It obviously undesirable to allow ambiguities to remain in an instance picture. We here give a definition of ambiguity, and in Section 4.3 give an algorithm for detecting it. In the rest of this section, we restrict our attention to only those arrows of a given type, such as read, since arrows of differing types cannot generate ambiguities.
Consider Figure 3. Although both positive and negative read arrows involve Alice, we interpret the picture to state that Alice is to have read access to her private directory. When determining whether a user has access to a file, an arrow that is most tightly nested at both its head and tail governs the sense of the access. In Figure 3 we say the positive arrow overrides the negative one.
An arrow a overrides another arrow d (with opposite parity) if a connects boxes that are contained in the boxes connected by a, where the box at at least one end of a is strictly contained in the box connected to a at the same end. A formal definition is given on page 23.
For example, in Figure 3, the positive read arrow connected to the Alice box overrides the negative read arrow connected to the World box. The reason is that their heads connect to the same box, and the tail of the former is attached to a box more tightly nested than (i.e., contained within) the box attached to the tail of the latter. In general, we can determine the status of a relation using this rule: A relation between u and / is unambiguous if there exists a single "certificate" arrow overriding all arrows of opposite parity connecting boxes containing u and /. If such a certificate does not exist, the relation is defined to be ambiguous. A picture is ambiguous when there exists some ambiguous relation between atomic boxes within it.
Thus, Figure 4 is ambiguous, since there is no certificate for the read relation between Bob and admin. 3. If the picture were unambiguous, then some arrow x would have to override >all arrows of opposite parity Thus only arrows 2 and 4 are candidates for being the arrow x. However, arrow 2 does not override arrow 3. and arrow 4 does not override arrow 1. Hence the picture is ambiguous. This example demonstrates that ambiguity cannot be determined locally.  Figure 8. It is not ambiguous -access is permitted from U to F since arrow 2 and arrow 3 override arrow 1. Although arrow 2 does not override arrow 3 and arrow 3 does not override arrow 2, this does not make the picture ambiguous since arrow 2 and arrow 3 are of the same parity.

Types
So far we have focused on the semantics of the relation defined by an instance picture as reflected by the arrows. We also associate type semantics with arrows and boxes. Each arrow or box object has a type. The type of an arrow is a subset of a user-specified finite set Any of access modes (e.g., Any = {read, write, execute}). The type of a box is a name plus a (possibly empty) set of attributes.
Each  Figure 9), and may have a default value.
Box type definitions provide a subtyping mechanism. Each type has at most one parent (i.e., there is no multiple inheritance). The root of the type tree is defined to be type Root, which has no attributes and is not a subtype of any other type. A subtype inherits all of the attributes of its parent type, and can add additional attributes of its own. There are two restrictions on the attributes that a subtype inherits: first, if an attribute is mandatory in the parent, it must be mandatory in the subtype, and second, an attribute which is optional in the parent may be mandatory in the subtype.
To create an object of a particular type, the user must supply a name and values for all of the mandatory attributes of that type, and may supply values for any of the optional attributes.

Constraint Language
The Miro instance language is capable of specifying file system security configurations for any operating system. However, the kinds of instance pictures users will draw will vary depending on the particular system they are specifying. In particular, the system architecture and local security policies will impose constraints on what should be considered a legal (realizable and acceptable) instance picture for that system. For example, an instance that is legal for Multics may be illegal for Unix. We use the constraint language to define legal instance pictures.
Constraints are assertions that the occurrence of some situation implies that some further condition must hold. Constraints are divided into two parts: the antecedent (or trigger) and the consequent (or requirement). For example, we may wish to specify the constraint. "Any time a user has write access to a file, he or she should also have read access to it.'' (This is the example given in Figure 2). In this case, the existence of write access is the trigger on the read access requirement. Both parts are expressed together in a single constraint picture. We describe shortly how these constraints are depicted and give a description of their semantics.
We would like our constraint language to be able to place restrictions on the following aspects of an instance picture: • Where arrows may be drawn (e.g.. "there can be at most 20 arrows leading to any box of type top-secret"). Such constraints specify certain syntactic relations among boxes because they depend solely on the syntax of the instance picture • Entries in the associated access matrix (e.g., "if a user has write access to a file, he should also have read access to it"). These constraints specify semantic relations among boxes because they depend on the meaning of the instance picture.
• Box containment relations (e.g., "every user in the Miro grouo should have a sub-directory contained in his or her home directory called miro").
In general, a single security requirement will involve a combination of these relations. For example, the constraint: "For every user named u in the system, there should be a directory named u in the /usr directory, and there should be a file called mail in that directory to which u has read access," is a combination of containment and semantic constraints; however, we can express this requirement with a single constraint picture.

Syntax and Semantics
Like instance pictures, constraint pictures contain boxes and arrows, but with restrictions and extensions to the instance picture syntax. Each constraint picture specifies a "pa-tern" which defines a (possibly infinite) set of instance pictures. If a particular instance picture matches the pattern, we say that instance is legal with respect to the constraint.
We now present an informal version of the syntax and semantics of the constraint language in an incremental fashion. At each step in the presentation we give examples of constraint pictures (constructed 9 from the syntax as described up to that point) and instance pictures, and explain why a particular instance picture does or does not match that constraint picture.

Boxes
The primitives in the constraint language are constraint boxes; each constraint box contains a box predicate taken from the box predicate language.
A particular box in an instance picture matches a constraint box if the values of the instance box's attributes make the predicate in the constraint box true. In an actual instance picture, there may be more than one box that matches a given constraint box. Similarly, each instance box may satisfy more than one constraint box.
The box predicate is a Boolean expression (where U L" "|," and "!" denote "and," "or," and "not," respectively) of relations involving constants and attribute names associated with some box type. We use C and C as relations on box types to denote subtype and strict subtype, respectively. We use variables to force attribute values of two or more boxes to match. A variable is distinguished from other identifiers by preceding it with a "$." Each variable $X in a constraint must appear in at least one predicate containing the expression "attribute = $X." The operational semantics of each variable in a constraint is as follows: Pick any box pattern in which the variable is compared to an attribute for equality and set the value of the variable to the value of the attribute of the box matching that box pattern. Then, for each other use of the variable in constraint boxes, substitute the assigned value for the variable; that substituted value must satisfy all of the box predicates.
The boxes shown in Figure 10 illustrate the basics of the box predicate language. The predicates match:

Arrows
There are three kinds of constraint arrows, one for each type of relationship between boxes (syntactic, semantic, or containment) we wish to constrain. We call the arrows associated with these relationships syntax arrows, semantics arrows, and containment arrows, respectively. Both the head and tail of a syntax or semantics arrow lie directly on the boundary of the boxes to which they are connected, whereas the head of a containment arrow lies inside its connected box. Syntax and semantics arrows are visually distinguished by drawing them with solid and dashed lines, respectively We also adopt the convention that syntax and semantics arrows are horizontal, while containment arrows are vertical. This convention is used only for pedagogical purposes in this paper; the language does not impose it. Examples of these arrows are shown in Figure 11. Syntax and semantics arrows are labeled, but containment arrows are not The label in the former two cases serves to further specify which type of relationship may exist between a and 6 Recall that Any is the set of allowed access types. In general, the label specifies some non-empty set 5 C Any. If 5 is a singleton set, we write it simply as s instead of { s }.
We now describe what it means for the boxes a and b to match the patterns .4 and B with respect to each type of arrow.
(a) Syntax Arrow: If there is a syntax arrow from A to B labeled 5, then there must exist an arrow in the instance picture from a to b of some type 5 6 5.

(b) Semantics Arrow:
If there is a semantics arrow from A to B labeled 5. then the access matrix associated with the instance picture must specify that a has some permission s on 6, where 5 6 5.
Furthermore, since the access matrix is only defined on atomic boxes, any box pattern having a semantics arrow incident to it can be matched by only an atomic box. Therefore, in this case, a and 6 can match their respective box patterns only if they are atomic.

Containment and Starred Containment
In instance pictures, we already have a powerful visual representation for containment, and we allow this representation in constraints as well. Drawing one box inside another is a shorthand for drawing a containment arrow between two non-intersecting boxes. Figure 13a shows the equivalence of these two representations We will see later that containment arrows (the left-hand side of the equality) provide more expressiveness than the box-inside-a-box representation (the right-hand side of the equality).
The constraint syntax also provides a means for specifying that a box is contained in another box at some level as opposed to being contained directly. A containment arrow with a star at its tip denotes this more general starred containment relation. Again, there is an equivalent graphical representation for starred containment in which one starred box is drawn inside another (Figure 13b).

IB '
(a) Figure 13: Direct containment (a) and containment (b) The semantics of a starred containment relation is straightforward Boxes a and 6 will match the constraint shown in Figure 13b if and only if a is contained in 6 (one or more levels deep). For example, the instance picture in Figure 12 would match constraint Figure 12(4) if the containment arrow were starred

Negated Arrows
Like instance arrows, each of the three kinds of constraint arrows may be negated, but the semantics is different in each case. In general, a negated syntax arrow matches a negated arrow in the instance, whereas a negated semantics arrow or containment arrow matches the negation of the relation that would be specified by the positive version of the arrow.
We now describe these semantics more formally by defining what it means for the boxes a and b to match the patterns A and B with respect to each type of negated arrow.

Thick and Thin
Recall that constraint pictures in their general form are composed of both a trigger and a requirement that must hold whenever the trigger is satisfied. We draw both parts of the constraint together and use line 13 thickness to distinguish the two parts; the objects that form the trigger are thick, and the objects that form the requirement are thin (on a color display system, we might use two colors, such as red and blue, instead of line thickness). The loose meaning of a picture with both thick and thin objects is. "For each part of the instance picture matching the thick part of the constraint, some additional part of the instance picture must match the thin part of the constraint." To specify conditions that must be true unconditionally, the entire constraint picture must be thin.  represented this constraint using that shorthand, we would represent both boxes and their thickness, and we would implicitly represent the containment arrow, but we would not be able to represent the thickness of that arrow. Therefore, we need a rule defining which arrow thickness to assume in order to make the box containment shorthand complete. The rule is: if both boxes are thick, the arrow is thick; otherwise, the arrow is thin.

Building Bigger Constraints
So far, we have only considered simple constraints composed of at most two boxes and a single arrow, but in fact a group of many boxes and constraint arrows may work together to specify a bigger constraint pattern.
We expect most constraint pictures to be relatively small, consisting of at most four or five boxes and three or four arrows. We require that no boxes overlap in these bigger constraints though strict containment is still allowed.
Given a more complex constraint picture, it is necessary to define carefully what it means for an instance to match that constraint. We first convert all instances of box containment in the constraint to the equivalent form using containment arrows and starred containment arrows. We now present some useful definitions.
A sub-picture of either an instance or a constraint is a (possibly empty) subset of the boxes and arrows comprising the original picture. It is important to note that a sub-picture need not be well-formed: it may have dangling arrows.
14 We now present the semantics for matching. To simplify our discussion, we ignore constraint arrows although the semantics below are easily extended to handle them. A sub-picture Pj of an instance P MATCHES a sub-picture Pc of a constraint if: • there is a one-to-one mapping a from box patterns of Pc to boxes of Pj such that for each box pattern b of Pc, the box a(6) satisfies the box predicate of 6, • there is a one-to-one mapping 3 from syntax arrows of Pc to arrows of P/ such that for each syntax arrow a (with label 5) of Pc, the type of (3(a) is in 5, • there is a one-to-one mapping 7 from semantics arrows of Pc to access matrix entries determined by P such that for each semantics arrow a (with label 5) of Pc the type of 7(a) is in 5. and • there is a one-to-one mapping from direct containment arrows (or starred containment arrows) of Pc We are now ready to define matching between entire instances and constraints. We first split the constraint picture Pc into its thick (trigger) and thin (required) sub-pictures, which we call Pj and PR respec- tively. An instance Pj is legal with respect to the constraint picture Pc if. for each sub-picture of Pj that matches Pj. there is another sub-picture of P; that, when combined with the first sub-picture, matches all of Pc Furthermore, the one-to-one mappings used in the latter matching must be extended functions of   Figure 17 uses a numeric range to specify one of the conditions implicit in the design of the Andrew file system. In Andrew, an access list of at most ten entries is associated with each directory. Figure 17 therefore states that any Dir may have at most ten arrows pointing at it.

Negative Constraints
Sometimes, it is more natural to express a constraint by depicting what should not be allowed. Negative

Example Constraints for Unix
In this section we present some possible constraints for the

Overview
In order to determine the effectiveness of the Miro languages, we are developing a collection of tools to support the creation and use of instance and constraint pictures. What makes some of these tools particularly novel are the non-trivial algorithms implemented to check for properties such as ambiguity. What makes the overall design of our Miro environment particularly interesting and useful for prototyping is the loosely-coupled way in which the individual tools interact.
We divide the set of tools into froni-end tools and back-end tools, as illustrated in Figure 19. We draw an analogy here with conventional compilers: these have a front-end that is system independent and a machine-specific back-end that handles code generation. The front-end Miro tools are independent of the file system structure of any specific operating system, while the back-end tools incorporate information about a particular operating system and its security policy.

Editor
The Miro editor tool allows a user to create, view, and modify instance and constraint pictures. Figures 20   and 21 show sample snapshots of editing sessions on an instance and constraint picture, respectively.  One problem with visual systems is the possibility of seeing too much information at once. The editor will provide several facilities for managing this information in the future, including zooming in and out, hiding the boxes inside any specified box, and scrolling vertically and horizontally across a large picture.

We built the editor on top of the Garnet user interface development environment [Mye88]. Garnet provides us
with an object-oriented graphics package, encapsulated input device handlers (interactors), and a constraint system to ease the pain of developing a graphical user interface. Garnet simplifies the creation of windows and menus. Its object-oriented nature provides a convenient mechanism for encapsulating attributes, and the interactors allow the selection and movement of compound objects. The Garnet constraint system gives us a way to specify restrictions on the manipulation of our graphical objects (e.g., the ends of arrows in an instance picture must always be attached to boxes, even when those boxes are moved). Garnet itself is built on top of the XI1 window system and Common Lisp.

Ambiguity Checker
Since our instance language allows for the creation of ambiguous pictures, and since ambiguity in instance pictures is not easily detected by a person, it is necessary to automate the process of checking an instance picture for ambiguity. Therefore, to perform the search for a certificate, we first partition A into the two sets A r and P of negative and positive arrows, respectively. If both N and P are empty, we can immediately conclude that the relation between u and / is neg since this is the default. If one is empty, but not the other, then we can also immediately conclude the relation between u and /.
Otherwise, both N and P are non-empty. We first search these sets to see if P contains a positive certificate. If so, the relation between u and / is pos. If not, we search N to see if it contains a negative certificate. If so, the relation between u and / is neg. Otherwise, we must conclude that the relation between u and / is ambig.
We now describe precisely how the search for a certificate is performed. Without loss of generality, say we are looking for a positive certificate. For each arrow p £ P, we check that p "overrides" all arrows n £ X.
If so, p is a positive certificate; if not, we try the next arrow in P. If there are no more arrows to try, then P does not contain a certificate. We now formally define what it means for p to "override" n. Let p u and Pf be the boxes attached to the tail and head of p respectively; similarly for n u and nj. Then p overrides n iff it is not the case that p u crisscrosses n u and pj crisscrosses ny, or that n u is contained in p u , or that nj is contained in pj.

Implementation
The ambiguity checker was written to be fast. As a result, it sometimes sacrifices space for speed. For example, the relation matrices are implemented as true two-dimensional arrays, incurring an 0(n 2 ) space cost; since these matrices may be sparse, it might be more practical to use some more space-efficient sparsematrix representation.
The boxes are stored in two linked lists: one for user boxes and one for file boxes. Each list is in two parts: non-atomic boxes appear first in the list, and atomic boxes follow them. A pointer to the first atomic box in the list is also stored so we can iterate either over all boxes or all atomic boxes of either type.
Each box in the input is given an internal name (sysname). An arrow is described by listing the sysnames of the boxes it connects (along with other information). The program uses a hash table to find a box quickly given its sysname. It also uses a separate hash table to store various identifiers such as legal entry names, legal attribute names, access modes, and other identifiers occurring in the input file.
We derived the reflexive-transitive closure algorithm run on each of the relation matrices from the algorithm discussed in sections 5.6 and 5.7 of [AHU74]. We made some simple modifications to this algorithm.
First, we used only two 0(n 2 ) arrays to store the previous and current results of the dynamic programming structures as opposed to the 0(n 3 ) space suggested. Second, our algorithm maintains the distinction between direct containment and indirect containment. Although the ambiguity algorithm does not require this distinction, it is free to maintain, and may be required by other tools.
The algorithm to add crisscrosses information to the relation matrices is straightforward. Two

Constraint Checker
The constraint checker, like the ambiguity checker, is a front-end tool. Given an instance picture and a constraint picture, the constraint checker will determine whether the instance picture is legal according to the given constraint. Hence this tool will ensure that a particular user's security configuration conforms to a given set of standards, perhaps specified by a system administrator. The constraint checker takes unambiguous instance and constraint pictures as input. The access matrix, computed by the ambiguity checker, must also be input if the constraint picture has any semantic arrows. Output consists of a boolean value that answers the question "Does this instance picture satisfy this constraint?", and optionally a message describing which instance boxes and arrows failed to satisfy the constraint.
Here is our idea for how to check an instance picture with respect to a constraint quickly. The constraint can be compiled into an abstract program, which can then be run on the input instance picture to implement

Back-end Tools
After completing our picture language and constraint language tools, we plan to work on a number of back-end tools that will provide direct interfaces with existing file systems. These back-end tools are the 24 file system specific probers and configurers.
A prober inspects an existing file system, compares it with an instance picture, and shows what differences exist. A configurer sets file protection bits and/or user privileges in a file system according to a given instance picture.
We anticipate that the back-end tools would be written calling a number of routines to inspect and make modifications to an existing file system. These routines would contain all the file system specific code, and separate versions of them could exist for each type of file system that Miro was used to specify, e.g.. Unix.
With these routines we can use the prober to analyze a file system and compute its access matrix. We then compare this access matrix to that described by an instance picture, perhaps discovering discrepancies in some entries. Upon discovering such discrepancies with the prober, one could either manually or automatically compare the file system with a given instance picture. 2. Update file system automatically. Alternatively, we can feed the list of discrepancies to the configurer which would then adjust file protections and/or process privileges to conform to the lowlevel access matrix given by the instance picture.
3. Update picture automatically. Rather than adjusting the file system automatically, as in alternative 2 above, or adjusting the picture manually, as in alternative 1 above, we might try to adjust the picture automatically. It is certainly possible to do this, since we can always find at least one representation of any access matrix: at the very least we can simply represent all files as atoms (without using any hierarchy) and all processes (or users) as atoms and draw the bipartite graph corresponding to the access matrix. Of course, such a naive representation would be no more comprehensible than a listing of the access matrix itself. What we really would want in this case is a "pretty printed" instance picture that would take advantage of the hierarchical structuring supported in the instance language.
Additional difficulties would be encountered if we insist that the "pretty printed" instance picture conform to an arbitrary constraint specification. These difficulties pose a number of challenging research problems. Indeed, in the extreme case, where the inputs to our automated "picture-update" algorithm are a complex file system configuration for an operating system with a highly flexible protection scheme (such as ITOSS [RT87] or HYDRA fWLH81]) and the empty instance picture, the likelihood of obtaining a satisfactory result seems dim, since there are too many equivalent alternative instance pictures possible. However, in the case where the number of discrepancies between the picture and the file system is small, we are likely to do better than in the worst case.
Support for the first two alternatives seems feasible, but the third option is considerably more difficult and would require the solution of some basic research questions.

Miro as a Security Specification Language
Miro demonstrates that it is possible to specify security visually. But how useful is it? Is Miro successful in its attempt to provide a single method for security specification while satisfying the joint requirements of rigor and straightforwardness? Consider first the requirement of mathematical rigor. In this paper, we have seen two examples of security specification languages, the instance language and the constraint language; certainly our formal semantics for the instance language shows that we can design a visual language that satisfies the strictest requirements of rigor. While we have not presented a formal semantics for the constraint language here, valid constraint pictures also have completely precise and unambiguous meanings.
It is impossible to make a definitive statement about how easy it is to use Miro without extensive user tests. Based on preliminary impressions, we believe that instance pictures are perspicuous to most users.
The constraint language is more difficult to master than the instance language. But the information captured by the constraint language would otherwise be expressed as an unstructured set of predicates in competing notations that are solely textual, such as those used to specify PSOS [NBF*80] or the Bell-LaPadula model.
In the design of the constraint language we have identified visual representations for the common idioms used in the security domain, abstracting away from the more difficult textual models. In short, our visual idioms would compile into these "assembly-lever 1 textual languages. The constraint language provides users with a concise yet expressive set of constructs with which to specify and evaluate different existing security models and to design and experiment with new, more ambitious models.
Moreover, tools such as our constraint checker and back-end tools will allow those who write visual specifications to recognize the consequences of their specifications more quickly. Using these tools, peo-

Mir6 as a Visual Formalism
Miro demonstrates the power of visual formalisms by giving two different semantic domains into which one syntactic domain (boxes and arrows) maps: access matrices (for instance pictures) and instance pictures (for constraint pictures). The fact that we were able to embed these very different domains in a common framework shows the flexibility and power of the Miro notation. To Harel's credit, much of this flexibility is inherited from his original work on higraphs [Har88].
The instance language works because it has a first-order universe primarily consisting of unary and binary relations over a hierarchical domain. There is nothing specific to security about this notation; with minor modifications the instance language could be applied to any set of object/entity relations (in Miro, we took these to be file-system accesses) taken over a set-theoretic domain (in Miro, these consist of files, groups of files, users, and groups of users). The most difficult challenge we faced in designing the instance language was in developing the exception mechanism, whereby an arrow could override a less deeply nested arrow, and then designing algorithms and tools to detect and disallow the ambiguous pictures that the exception mechanism introduced.
In contrast, the constraint language pushes the higraph notation much further. Here we needed each constraint picture to specify some set (typically infinite) of all legal instance pictures. As argued above, this has been a very challenging problem in the past for text-based specifications. In essence, what we have done is to allow quantification and implication over our first-order properties to be expressed in a visual notation. The three types of relations expressed by our arrows are quite different: in the case of syntax and containment arrows we are expressing relations that would be immediately visible only from the syntax of the instance language pictures. On the other hand, the semantic arrow expresses relations that result from the interpretation of our instance pictures. In other words, the semantics of our constraint pictures quantifies over the semantics of our instance pictures as well as the instance picture's syntactic properties.
We only carried this meta-semantics to one level; if Miro were used for specifying domains more complex than security, we might want to nest these meta-levels of semantics more deeply.
Even in the area of security, this meta-semantics could be exploited a second time. We might consider introducing a transition language that could express the dynamics of file system protections. This sort of picture would allow us to answer the questions such as, "Given a single instance picture, to which other instance pictures can we legally move in a single operating system action?" or "Given an instance picture A, can we move to an instance picture B without going through any "dangerous" (i.e., insecure) instance pictures?". If we view each instance picture as a node, then the transition language expresses the directed graph showing how we can legally move from one node to another node. We could then further generalize by defining a language of constraints on transition pictures, or a transition language on constraint pictures (to specify legal changes to security policies). We believe that these sorts of meta-semantic hierarchies on visual languages can find wide use in many application domains.

Areas for Further Research
As currently defined, Miro facilitates prototyping security models. Miro by itself, however, has opened a number of research problems such as: higraph-layout problems introduced by our back-end tools, more efficient ambiguity checking algorithms, constraint checking algorithms that are almost always fast, formal specification of graphical properties and operations, and the application of the Miro languages to areas other than security.

A Formal Semantics of the Instance Language
Although the instance language itself is primarily visual, we give its semantics in a well-known denotational language: the language of mathematics. We build propositions out of set theoretic constructs, and use first-order logic to reason about them. Table 3 lists the definitions we will need to build these propositions. Table 3 defines the representation for all objects in our figures. It also defines some operators: subboxes of one box (<r), subboxes of many boxes (r), and all subboxes of many boxes (r').
[MTW89] describes this table in more detail than we do here. Given this formal representation, we can construct predicates that express object interaction. In particular, we need to say how different boxes are related, and which arrows join which boxes. We present these set constructors and predicates below; they are illustrated in Figure 22 and Table 2. Free variables (x, y, P, P', TV, N') in the definitions below range over elements in BOXES. Figure 22: Illustration for the auxiliary definitions  Table 2: Some properties of the picture in Figure 22 Before beginning the presentation, we must clarify some aspects of our notation.   Figures 1 and 3 pendix, indentation is used to reduce the number of parentheses, negation symbols (-») will bind more closely than conjunction (A), and conjunction will bind more closely than disjunction (V). Implication is less restrictive than these, but will bind more closely than the quantifiers (V, 3). The symbol (W) will be used to denote the union of two disjoint sets, and ( = ) will be used to define new constructs

X | members(X) tnstde-of(X) contains(X) crtsscrosses(X)
The final access matrix does not depend on the shapes of boxes, but rather, on which atoms are contained in each box. The set constructor members gives us the set of all atoms contained within a box. The other set constructors use members in their definitions.

members(x) i { a | a £ ATOMS A a£ r m ({ x }) }
Many pictures have boxes that nest in a hierarchical fashion. We use mstde-of and contains to give us the descendants and ancestors of a particular box.

tnside-oJ[x) = { b \ b £ BOXES A members(b) C members(x)} contams(x) = { 6 | b £ BOXES A members(x) C members(b)}
However, we do not require strictly hierarchical pictures; pictures may contain overlapping boxes. We define the set crisscrossesfx) and operator >4 to represent overlapping boxes. These will be useful in the Closure Lemma below.

POS l (P, P') = (P, />', r\ pos) £ ARROWS NEG l (N, N') i (N, A r \ i, neg) £ ARROWS
To clarify the interactions of these definitions, we introduce the concept of box level and the Closure Lemma. Box level refers to the hierarchy imposed on boxes through containment. Two boxes are said to be at the same level if and only if X >4 Y. 3 If X £ tnside-of (Y), Y is said to have a higher level than box A', and X a lower level than box Y. In Figure 23, A and B have the same level, neither C nor D is related bylevel to any other box (since they have no members in common), F has a lower level than E has a higher level than F, and F has the same level as itself. Figure 23: Illustration of box level.

B
The following lemma illustrates some relationships among these definitions.
3 Just a* a is not transitive, neither is AT THE TAME LEVEL.

// two boxes B. B' both contain the same itomic box. then exactly one of B >< B'.
B € inside-of (B 1 ), or B' € inside-of (B) is true.
The interpretation of an instance picture in the security domain is an access matrix. The access matrLx Z is three-dimensional, with axes being Processes, Files, and types of Relations.
Entries in the matrix range over values pos, neg, and ambig. Let t be the type of the relation, p an atomic box representing the process, and / an atomic box representing the file. The interpretation is that if Z (p, f t) is pos then process p can access file / according to relationship type t. If Z (p, f t) is neg, then p cannot access / according to t. If   Z (p, f, t) is ambig, the access cannot be determined. We want to detect and eliminate all such ambiguity in the matrix.
In what follows, P and P' will identify the boxes at the tail and head, respectively, of a positive arrow, [ 00 iV € inside-of (P) Z is positive when the smallest enclosing boxes have only positive arrows; call these boxes P and P'. We require that no negative arrow join the following pairs of boxes: boxes at the same level as P and P' (case |T] above), one box at a lower level than P or P', and the other box at any level (cases [5] and 00 above).

^POS'iB, B') A ^NEG'(B, B')
Z is negative when the smallest enclosing boxes have only negat ve arrows (call these boxes .V and A"'), or when no surrounding boxes are connected by arrows. In the former case, we require that no positive arrow join the following pairs of boxes: boxes at the same level as A' and .V (case Q] above); one box at a lower level than N or A r/ , and the other box at any level (cases [7] and [3] above).

Z{p.f< t) is ambig otherwise.
(3) The value of an element of Z is ambiguous when neither a positive nor a negative relationship holds An explicit derivation of those pictures that are ambiguous follows. Finally. Equation 4 gives the closed-form definition of ambiguity.