Formal Semantics for Programmable Access Control (PART A)

1. Formal Semantics for Programmable Access Control (PART A) by Ioanna Dionysiou

2. System Security (brief definition) • MOOSE project • Meta Object Model (MOM) components and functionality • MOM Authorization Model • Denotational Semantics for MOM Authorization Model • Results and Conclusions Presentation Outline

3. System Security “Protection afforded to an automated information system in order to attain the applicable objectives of preserving the integrity, availability and confidentiality of information system resources” NIST Handbook National Institute of Standards and Technology

4. System Security • How can system security be achieved? • Authorization • Authentication • Auditing • Secure communication

5. Heterogeneous Distributed Systems “You know you have one when the crash of a computer you’ve never heard of stops you from getting any work done” (CPTS 564 Notes – Very Interesting Definition) Any examples?

6. Difficult to achieve because…. Software components on distributed systems are typically heterogeneous (different languages and systems) Authorization policies are fixed to specific systems No flexibility to encompass other models Global Enforcement of Confidentiality and Authorization for Heterogeneous Distributed Systems

7. What has been done so far? Global Enforcement of Confidentiality and Authorization for Heterogeneous Distributed Systems CORBA Common Object Request Broker Architecture OLE/COM Object Linking and Embedding/Common Object Model

8. Global Enforcement of Confidentiality and Authorization for Heterogeneous Distributed Systems, Cont. Secure interoperability is prevented due to semantic diversity and complexity at the policy and model level Is there a solution?

9. Programmable Security Introduce new syntax for security policy expressions Common architecture that embeds programmable security constructs at a fundamental level Primitive security mechanisms tied to syntax within a common model for object systems

10. Formal Methods are NEEDED!!!! Mathematical techniques for specifying and verifying system properties ROC – formalism for concurrently executing objects Distributed system verification HOL – logic for reasoning and verification

11. MOOSE Architecture(Meta Object Operating System Environment)

12. MOOSE Architecture • Supports an architecture for the development, execution, and verification of secure heterogeneous distributed systems • Meta Object Model – core distributed object model within MOOSE that supports primitive object functionality

13. Meta Object Model (MOM) • Primitive distributed object model • Classes and inheritance through meta objects and delegation • Supports core object functionality (method invocation, asynchronous message passing, delegation, aggregation) • Provides a common substrate for secure interoperability between heterogeneous object systems

14. Message Handler Fi L ter Msg Metadata Repository Object Registry Component Type Misc. Msghan1 Msg_H . . . Objreg1 OR . . . OR OACL Object Access Control List Component Privilege Key Method_Interface_1 Key a Method_Interface_1 Lock a Method_Interface_1 All q Method_Interface_2 Key q Method_1 Lock a Method_2 Key b Message Handler Object Registry Metadata Repository Method Interface2 Object Access Control List Method Arbiter2 Method Body2 A Msg MOM Components

15. Message Handler(MOM Components) Main Function : constrain the set of messages that objects receive from their environment Receipt of a message from message handler Accept it as a local request (that’s not authorization!!) Delegate it to adjacent domain

16. Object Registry(MOM Components) Main Function : bookkeeping information associated with each object component Local identifier of the object component Miscellaneous information Component type

17. How can the object registry be used? Object Registry – An example(MOM Components) Component Type Misc o1 MOM-Object o2 MOM-Object Object Registry for root Incoming message contains an invocation request for a method responsible for creating object named o2. Deny or accept?

18. Meta Data Repository(MOM Components) Main Function :contains templates needed to define meta object instances Object o2 can create instances containing subobjects X and Y and methods M1 and M2. Initial Authorization State of o3 Suppose o3 is a new instance of o2.How can the meta data table for o2 be used? And why?

19. Methods(MOM Components) Method Interface Accepts method Invocation Manages synchronization constraints on methods Method Arbiter Establishes communication channels between the method body and its environment Method Body Performs the actual work – only communicates with the arbiter

20. Methods – An example(MOM Components) msg Method interface m1 Method arbiter m1 Method body m1

21. Object Access Control List(MOM Components) Main Function : defines the local authorization state for the MOM objects KEY or LOCK or recursive < Component, Privilege, Token > ticket

22. Component Privilege Ticket Method_1 Lock a Method_2 Key b Object Access Control List(MOM Components) Method_1 has a Lock privilege associated with ticket a.

23. MOM Authorization Scheme • Object Access Control Lists (OACLs) • Message Filters • Messages and Tickets

24. o1 t1 Msg. with Ticket t1 o2 t1 Ticket-Based Scheme

25. Invoke Method_1 using ticket a Method_2 Check OACL if Method_2 holds ticket a F i l ter OACL Request denied No entry found Message Filtering

26. Original Authorization Model Semantics • Captured by five rules • Mostly focused on adding/removing privileges • Ignores hierarchical structure of objects (assumes direct access between objects) Object B Object A Universal Object Domain Object C

27. Object hierarchy IS important An object can intervene and deny access Refined Authorization Model Semantics A B C

28. Refined Authorization Model Semantics • Object hierarchy taken into account • Message delegation (authorization of message at each passing object in the hierarchy) HOW?

29. Can A access C? Can A access D? Can A access m? A B C D yes yes Invoke method m in D Authorization During Delegation

30. PARENT predicate ADJ predicate ANCESTOR predicate DESCENDANT predicate LOCK predicate KEY predicate GRANT.p predicate REVOKE.p predicate MATCH predicate ACCESS predicate ADD command REMOVE command Refined Authorization Model