1A pattern language for security modelsEduardo B. Fernandez and Rouyi PanDept. of Computer Science and Eng.Florida Atlantic UniversityBoca Raton, FL [email protected] is a serious problem in the Internet and it is necessary to build new systems incorporatingsecurity as integral part of their design. The use of patterns is a good tool to help designers buildsecure systems. We discuss three patterns that correspond to the most common models for security:Authorization, Role-Based Access Control, and Multilevel Security. These can be applied in all thelevels of the system and we show their use in the definition of a pattern for file authorization.1. IntroductionSecurity is a very important aspect of any computing system, and has become a serious problem sinceinstitutions have opened their databases to the Internet. Most web systems in current use have notbeen designed with security in mind and patches have failed to make them more resistant to attacks. Itis important to develop systems where security has been considered at all stages of design, which notonly satisfy their functional specifications but also satisfy security requirements [Fer00a]. To do thiswe need to start with high-level models that represent the security policies of the institution. Thereare three models currently used by most systems: the access matrix, the Role-Based Access Control(RBAC) model, and the multilevel model.Security encompasses all the architectural levels of a system [Fer99]. The Layers architectural pattern[Bus96] is therefore the starting point of this pattern language. This pattern provides a structure wherewe can define patterns at all levels that together implement a secure system. Its main idea is thedecomposition of a system into hierarchical layers of abstraction, where the higher levels use theservices of the lower levels. Here it provides a way to put things in perspective and to describe themechanisms needed at each layer. We have discussed earlier [Fer99], why all these levels must becoordinated to assure security. Figure 1 shows the specific set of layers we consider. This figureshows some of the participants at each layer and their correspondence across layers.Due to the complexity of the problem, we need a series of pattern languages, one per level. We startin this paper with a pattern language for abstract models; this includes the three basic modelsmentioned above. These models define security constraints at the highest architectural level for theapplications, which are enforced by the lower levels. These models have been extensively studied bythe security community [Pfl97, Sum97], and we do not attempt here to add new models or extend the Copyright  2001, Eduardo B. FernandezPermission is granted to copy for the PLoP 2001 Conference. All other rights reserved.2existing models. Our intent is to specify the accepted models as object-oriented patterns that can beused as guidelines in the construction of secure systems. We show also how these patterns can beapplied to all the system levels.We present first the Authorization pattern that describes access control for resources. We thendescribe in Section 3 the RBAC pattern as an extension of the Authorization pattern.The MultilevelSecurity pattern is shown in Section 4. After this we discuss how to apply the patterns to the lowerlevels and show a pattern for file access control as an example of a specialization of the Authorizationpattern. We end with a discussion of general aspects common to these patterns. Figure 1. An instance of the Layers pattern2. Authorization patternContextAny computational environment where there are active entities that request resources whose accessmust be controlled.Aa. m1 b. m2 c. m3classesMetalayerobjectsApplicationlayerexecutingprocessesSystem layer(OS/DBMS)nodesNode1 Node2processorsnetworkCPU1 CPU2 CPU3ProtocolDistributionlayerHardwareConfigurationa:ABCb:Bc:C3ProblemHow to describe allowable types of accesses (authorizations) by active computational entities(subjects) to passive resources (protection objects).Forces• The authorization structure must be independent of the type of resources, e.g., it should describeaccess by users to conceptual entities, access by programs to operating system resources, etc., in auniform way.• Predicates or guards may restrict the use of the authorization according to specific conditions.• Some of the authorizations may be delegated by their holders to other subjects.SolutionRepresent the elements of an authorization rule as classes and associations. Class Subject describesthe active entities, while class ProtectionObject describes the requested resource. An authorizationrule is defined by an association between these two classes. An association class, Right, includes thetype of access allowed (read, write,…), a predicate that must be true for the authorization to hold, anda copy flag that can be true or false indicating if the right can be transferred or not. An operationcheck_rights can be used in the subject or object to check the validity of a request. Figure 2 shows theelements involved.The sequence diagram of Figure 3 shows a request validation. ActiveSubject is an actor, e.g., anexecuting process, that requests some resource. This request is intercepted by a Reference monitor. Figure 2. Authorization patternConsequencesThe advantages of this pattern include:• The pattern applies to any type of resource. Subjects can be executing processes, users, roles, usergroups. Protection objects can be transactions, memory areas, I/O devices, files, or other OSresources. Access types can be read, write, execute, or methods in higher-level objects.SubjectidProtectionObjectid* *Authorization_rule Rightaccess_typepredicatecopy_flagcheckRights4• The predicates in the rules are a general representation of any conditions that may restrict theapplication of a rule.• The copy flag in the rule controls transfer of rights. However, some systems do not allow transferof rights, i.e., their copy flags are always false.• Some systems separate administrative authorizations from user authorizations for further security(principle of separation of duties) [Woo79].• The request may not need to specify the exact object in the rule, this object may be implied by anexisting protected object [Fer75]. Subjects and acess types may also be implied. This improvesflexibility at the cost of some extra processing time (to