Implementation of Mandatory Access Control in Role-based Security System. CSE367 Final Project Report. Professor Steve Demurjian. Fall 2001.

Implementation of Mandatory Access Control in Role-based Security System CSE367 Final Project Report Professor Steve Demurjian Fall 2001 Jin Ma Computer Science & Engineering The University of Connecticut Storrs, CT 06269-3155

Contents Abstract 1. Introduction 2. Access Control Models 2.1 Mandatory Access Control (MAC) 2.2 Role-based Access Control (RBAC) 2.3 Combination of MAC and RBAC 3. Framework of Existing Role-based Security System 3.1 Software Architecture 3.2 The Unified Security Resource (USR) 4. Implementation 4.1 Modify Database Schema 4.2 Modify Resource Information 4.3 Modify Security System 4.4 Modify IDL 4.5 Modify GUI 4.6 Some ScreenShots 5. Conclusion and Future Work 6. Reference 1

Abstract Role-based access control has been introduced along with claims that its mechanisms are general enough to incorporate the traditional access control models: mandatory access control (MAC) and discretionary access control (DAC). This report provides a realization of mandatory access control in an existing role-based security system by labeling all users with clearances and all other data objects with classifications. Implementation steps are presented and future direction is discussed. 1. Introduction Role based access control (RBAC) has recently received considerable attention, particularly for commercial sectors. Under the RBAC framework, users are granted membership into roles based on their competencies and responsibilities in the organization. This simplifies the administration and management of privileges; roles can be updated without updating the privileges for every user on an individual base. Role-based Access is generally recognized as being the most flexible form of access control [4,5]. Traditional mandatory access control (MAC) is associated with military or sensitive national security information and incorporates the policy of onedirectional information flow in a lattice. Mac is not as flexible as RBAC, yet MAC features are often required in, for example, military operations, where the flexibility of RBAC is also beneficial. Since the introduction of RBAC, researchers have discussed the relationship between RBAC and these traditional models [4] and attempted approaches on configuring RBAC to enforce MAC and DAC models. Nyanchama [2] proposes a number of access constraints that would realize the equivalent of Bell and LaPadula read- 2

down and write-up rules. Sandhu [8] attests the flexibility of RBAC and its ability to accommodate MAC policies by suitable configuration of role hierarchies and constraints. This paper introduces the implementation of mandatory access control in an existing role-based security system. In section 2, we will review the MAC and RBAC models. Section 3 discusses framework of the existing role-based security system. Section 4 presents the detailed implementation of MAC in a RBAC system. Section 5 offers conclusion and future directions. 2. Access Control Models 2.1 Mandatory Access Control Mandatory access control, which, according to the United States Department of Defense Trusted Computer System Evaluation Criteria is a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (e.g. clearance) of subjects to access information of such sensitivity. Clearance is the security level to which and individual user or client can access information. This clearance is usually associated with a need to know requirement. We will use the following four security clearance values according to National Security Information: Top Secret (T): shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause exceptionally grave damage to the national security. Secret (S): shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause exceptionally serious damage to the national security. 3

Confidential (C)): shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause exceptionally damage to the national security. Unclassified (U): no security restriction Classification is the security level given to information based on policy, We will use the same classification levels used for clearances to assign classifications. Clearance and classification go together, in that, a user s clearance is a limit to the access of information based on the information s classification. Classification relation is null < U < C < S < T. Each security level is said to dominate itself and all others below it in this hierarchy. The concept of mandatory access control was first formalized by Bell and LaPadula Model [4, 7]. The Bell-LaPadula Model supports mandatory access control by determining the access rights from the security levels associated with subjects and objects. The following two rules define the mandatory access: Simple-security property (ss-property): A subject can read an object only if the security level of the subject is higher or equals to the security of the object (readdown) *.property: A subject can write on an object only if the security level of the object is higher or equals to the security level of the subject. (write up) MAC policy compares the sensitivity label at which the user is working to the sensitivity label of the object being accessed and refuses access unless certain MAC checks are passed. It is usually assumed that the security labels on subjects and objects, once assigned, cannot be changed (except by the security administrator). This assumption 4

is known as tranquility[6]. This is the reason that MAC is mandatory. With mandatory controls, only administrators and not owner of resources may make decisions that bear on or derive from policy. Only an administrator may change the category of a resource, and on one may grant a right of access that is explicitly forbidden in the access control policy. MAC requires all those who create, access and maintain information to follows rules set by administrator. 2.2 Role-based Access Control RBAC regulates a user s access to certain resources based on a user role. A user role is a collection of permissions the user needs to accomplish that role. A user may have multiple roles, with each role having a set of permissions. The major advantage of role-based system is flexibility[1,9]. Role-based approach to protection and management of system privilege offers more flexibility than other systems such as multilevel security (the most common approach of MAC) and DAC, while proving similar levels of protection for objects in a system. In role-based applications, a user s access rights can be varied via different means. For instance, revoking a user s authorization to a role takes away the privileges in that role from the user. Fine-grained privilege management can be realized by removing/adding privileges associated with a given role. Another advantage of role-based system relates to the granularity of system privilege management. Given that system privileges can be as fine-grained as one can choose, roles offer a means for their incremental management. 5

2.3 Combination of MAC and RBAC Role-base access control eases the administration of privileges due to the flexibility with which roles can be configured and reconfigured. With roles, we can enforce the principle of least privilege where a role is assigned only sufficient functionality to realize the intended duty requirements [2]. Traditional role-based security finds application in environments where the greater concern is information integrity as opposed to secrecy [2]. Yet this does not preclude the exploitation of the advantages of role-based protection to realize secrecy. With additional rules on update and read operations, and the information they access, we can realize the requirements of mandatory access control, or MAC. It s out intention to demonstrate that a MAC-like level of protection can be realized using role-based security. 3. Framework of Existing Role-based Security System 3.1 Software Architecture In Figure 1, we represent the security-related clients and resources that comprise our new system architecture. We have a Unified Security Resource (USR), which provides role-based security support in Distributed Resource Environment (DRE). USR provides four categories of services: 1. Security Policy Services define user roles (UR s), register the resources, services and methods, and grant access to roles for resources, services and/or methods. Security Policy Services also include several methods that are provided for resource servers to publish themselves, their services and methods. 6

2. Security Authorization Services are utilized to maintain profiles on the clients (e.g. users, tools, software agents, etc.) that are authorized and actively utilizing nonsecurity services. These services allow a security officer to grant users to roles. 3. Security Registration Services are utilized by clients at start-up time for identity registration (User id, IP address and user role). 4. Security Tracking and Analysis Services are utilized by the security officers to dynamically trace the activities in the security environment and statically analyze the inner method calls of the resource server. Security Policy Client (SPC) Security Authorization Client (SAC) Global Clock Resource (GCR) Unified Security Resource (USR) Security Policy Services Security Authorization Services Security Registration Services Analysis Client Security Tracking and Analysis Java Client Software Agent Wrapped Resource for Legacy Application Lookup Legacy Client Database Client COTS Client Lookup Service General Resource Wrapped Resource for Database Application Wrapped Resource for COTS Application Service Figure 1: Security Clients and Resources in Distributed Environment. The prototype of our system has a USR and three resource systems, Global Clock Resource, Course Database Resource and the Patient Database Resource. Global Clock is a time server that is used to make sure database entries are entered in the proper sequence in a distributed environment. The Course Database Resource comes with a server and a client. In the server, we have three services: Query Services, Registration Service and 7

Update Service. Each of these services has a couple of methods. The Course Database Resource Client is used to access USR for registering clients and accessing Course Database Server for actions. The Patient Database Resource comes with a server and a client. In the server, there are three services: Query Services, Update Service and Membership Service. Each of these services has a couple of methods. The Patient Database Resource Client is used to access USR for registering clients and accessing Patient Database Server for actions. 3.2 The Unified Security Resource (USR) The Unified Security Resource (USR) is a repository for all static and dynamic security information on roles, clients, resources, authorizations, etc., and is organized into a set of services, as given in Figure 2. Register Service Register_Resource(R_Id); Register_Service(R_Id, S_Id); Register_Method(R_Id, S_Id, M_Id); Register_Signature(R_Id, S_Id, M_Id, Signat); UnRegister_Resource(R_Id); UnRegister_Service(R_Id, S_Id); UnRegister_Method(R_Id, S_Id, M_Id); Unregister_Token(Token) Query Privileges Service Query_Resource(); Query_Method(R_Id); Query_MethodDesc(Token, R_Id, S_Id, M_Id); Check_Privileges(Token, R_Id, S_Id, M_Id, ParamValueList); User Role Service Create_New_Role(UR_Name, UR_Disc, UR_Id); Delete_Role(UR_Id); Query_Role(UR_Id) SECURITY AUTHORIZATION SERVICES Authorize Role Service Grant_Role(UR_Id, User_Id); Revoke_Role(UR_Id, User_Id); Client Profile Service Verify_UR(User_Id, UR_Id); Query_Client(User_Id); Erase_Client(User_Id); Find_Client(User_Id); Find_All_Clients(); SECURITY POLICY SERVICES Figure 2: The Services of USR. Constraint Service DefineTC(R_Id, S_Id, M_Id, SC); DefineSC(R_Id, S_Id, M_Id, SC); CheckTC(UR_Id, R_Id, S_Id, M_ID, CheckSC(UR_Id, R_Id, S_Id, M_ID, ParamValueList); Grant-Revoke Service Grant_Resource(UR_Id, R_Id); Grant_Service(UR_Id, R_Id, S_Id); Grant_Method(UR_Id, R_Id, S_Id, M_Id); Grant_SC(UR_Id, R_Id, S_Id, M_Id, SC); Grant_TC(UR_Id, R_Id, S_Id, M_Id, TC); Revoke_Resource(UR_Id, R_Id); Revoke_Service(UR_Id, R_Id, S_Id); Revoke_Method(UR_Id, R_Id, S_Id, M_Id); Revoke_SC(UR_Id, R_Id, S_Id, M_Id, SC); Revoke_TC(UR_Id, R_Id, S_Id, M_Id, TC); SECURITY REGISTRATION SERVICES Register Client Service Create_Token(User_Id, UR_Id, Token); Register_Client(User_Id, IP_Addr, UR_Id); UnRegister_Client(User_Id, IP_Addr, UR_Id); IsClient_Registered(Token); Find_Client(User_Id, IP_Addr); SECURITY TRACKING AND ANALYSIS SERVICES Tracking Service Logfile(Log String) Analysis Service Analyze(Java Class File) 8

Security Policy Services are utilized to define, track, and modify user roles, to allow resources to register their services and methods (and signatures), and to grant/revoke access by user roles to resources, services, and/or methods with optional time and signature constraints. Security Authorization Services are utilized to maintain profiles on the clients (e.g., users, tools, software agents, etc.) that are authorized and actively utilizing nonsecurity services, allowing a security officer to authorize users to roles with or without time constraints. Security Tracking and Analysis Services are utilized to dynamically track all the activities in the security environment and to statically analyze the inner method calls of the resource system. 4. Implementation We implemented mandatory access control in Patient DB using CORBA. Application (here Patient DB) predefines the security classification (T, S, C, U) for resource, service and method. We define the lowest security level of methods as the service classification level, and the lowest security level of services as the resource classification level. A classification level is assigned to a role when created. And a clearance level is assigned to a user when created. When granted a role, the user should have the equal or higher clearance than the role. 4.1 Modify Database Schema The bolded columns are added to the database table to hold on the security classification or clearance information. 9

table users (user_id, passwd, begin_time, end_date, end_time, description, clearance) table role (role_id, description, classification) table res (res_id, begin_date, begin_time, end_date, end_time, description, classification) table service (res_id, service_id, service_name, description, classification) table method (res_id, method_id, method_name, description, classification) table availres(res_id,begin_date,begin_time,end_date, end_time, description, classification) table availservice (res_id, service_id, service_name, description, classification) table availmethod (res_id, method_id, method_name, description, classification) 4.2 Modify Resource Information PDBSourceID.java: assign security classification to resource, service, and method. Unclassified: PatientDB Resource Unclassified: Query Service Classified: Update Service Unclassified: Membership Service Top Secret: writeprescription(), getpresctiption; Secret: getmedicalhistory(), writediagnosis(), getdiagnosis(); Classified: getpaymentmod(), setpaymentmode(); Unclassified: addpatien(), removepatient(), getpatientlist(); PDBCorbaImpl.java: need to modified the parameters of related methods. For example, the bolded column is newly added. _security.resourceregister(pdbresourceid.patient_db_res_name, PDBResourceID.PATIENT_DB_RESOURCE_DESCRIPTION, PDBResourceID.PATIENT_DB_RESOURCE_CLAS); Note: we did not start University Database during the demo because hui only implemented snapshop on PDB. My part could work with University Database also. UDBSourceID.java: assign security classification to resource, service, and method. UDBCorbaImpl.java: need to modified the parameters of related methods. For example, the bolded column is newly added. 4.3 Modify Security System 10

SecurityDelegate.java: modify all methods which has parameter changes or the SQL statement querys table which adds new column. SecurityCorbaImpl.java: add following new methods. public String queryresourceclas(string resourceid); public String queryserviceclas(string resourceid, String servicename); public String querymethodclas(string resourceid, int methodid); public String[] queryavailserviceclass(string resourceid); public String[] queryavailmethodclass(string resourceid); public String[] queryregisteredmethodclass (String resourceid); public String[] queryservicemethodclass (String resourceid,in wstring serrviceid); public String[] queryregisteredserviceclass (String resourceid); public String[] queryregisteredresourceclass(); public String queryroleclas (String roleid); public String queryuserclearance (String userid); SecurityCorbaImpl.java: Modify the hasclientright Method to check for MAC after token check 4.4 Modify IDL Add following IDL code to securityserver.idl wstring queryresourceclas(in wstring resourceid); wstring queryserviceclas(in wstring resourceid, in wstring servicename); wstring querymethodclas(in wstring resourceid, in long methodid); seq1_string queryavailserviceclass( in wstring resourceid); seq1_string queryavailmethodclass( in wstring resourceid); seq1_string queryregisteredmethodclass (in wstring resourceid); seq1_string queryservicemethodclass (in wstring resourceid,in wstring serrviceid); seq1_string queryregisteredserviceclass (in wstring resourceid); seq1_string queryregisteredresourceclass(); wstring queryroleclas (in wstring roleid); wstring queryuserclearance (in wstring userid); 4.4 Modify GUI Modify GUI code to allow a security admin to enter classifications for roles, and clearances for users. Modify every GUI tab to allow classification (clearance) information appropriately displayed, and check for MAC. AddMethodToServiceTab.java CreateRoleTab.java GrantIPTab.java 11

GrantMethodTab.java GrantResourceTab.java GrantServiceTab.java QueryResourceTab.java QueryRoleTab.java RegisterMethodTab.java RegisterResourceTab.java RegisterServiceTab.java CreateUserTab.java EraseUserTab.java GrantRoleTab.java QueryUserTab.java Modify RefreshThread.java in both Policy and Authorization GUI to make sure the GUI tabs are updated appropriately. 4.5 Some Screenshots When Patient DB server starts, the predefined classification information is loaded. Available resource is displayed with appropriate classification level. 12

13

Since we use the lowest level of all methods classification as the security level of the service, a method with lower level than the service cannot be added to that service. Query resource result is displayed with classification level. 14

Role doctor is created with Top Secret classification. 15

Method cannot be granted to the role because its classification level is higher than that of the role. 16

User hui is created with Top Secret clearance. 17

A lower level user cannot be granted higher level role. 5. Conclusion and Future Work We implemented a realization of mandatory access control in an existing rolebased security system by labeling all users with clearances and all other data objects with classifications. Our approach is to treat clearances and classifications as constraints and it fact, that is what they are. A practical consequence is that it might be better to develop systems that support general RBAC and specialize these to MAC. It is also practical to build rules for adjustment. 18

6. Reference 1. Nyanchama, M. & Osborn, S. 1993. Role-Based Security: Pros, Cons & Some Research Directions. ACM SIGSAC Review, 2(2): 11-17, June 1993 2. Nyanchama, M. & Osborn, S. 1996. Modeling mandatory access control in role-based security systems. In proceedings of the IFIP Working Group 11.3 Working Conference on Database Security. Elsevier North-Holland, Inc., Amsterdam, The Netherlands, 37-56. 3. Osborn, S. 1997. Mandatory access control and role-based access control revisited. ACM Trans. Inf. Syst. Secur. 1, 2(Feb.), 3-33. 4. Osborn, S., Sandhu, R., and Nunawer, Q. Configuring Role-Based Access Control To Enforce Mandatory And Discretionary Access Control Policies. ACM Trans. Info. Syst. Security, 3, 2, 2000. 5. Philips, C.E., Ting, T.C. and Demurjian, S.A. Information Sharing and Security in Dynamic Coalitions 6. Sandhu, R.S. 1993. Lattice-based access control models. IEEE Computer 26, 11, 9-19. 7. Sandhu, R. S.and Samarati, P. 1994. Access control: Principles and practice. IEEE Commun. Mag. 32, 9, 40-48. 8. Sandhu, R.S. 1996. Role hierarchies and constraints for lattice-based access controls. In Proceedings of the Conference on Computer Security (ESORICS 96, Rome, Italy), E. Bertino, H. Kurth, G.Martella, And E. Montoliva, Eds. Springer-Verlag, New York, NY, 65-79. 9. Sandhu, R.S., Coyne, E.J., Feinstein, H.L., and Youman, C.E. Role-based access control models. Computer, 29:38-47, Feb. 1996. 19