Formal semantics for programmable access control part a
Download
1 / 30

Formal Semantics for Programmable Access Control (PART A) - PowerPoint PPT Presentation


  • 251 Views
  • Uploaded on
  • Presentation posted in: Pets / Animals

Formal Semantics for Programmable Access Control (PART A). by Ioanna Dionysiou. 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

Download Presentation

Formal Semantics for Programmable Access Control (PART A)

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Formal Semantics for Programmable Access Control (PART A)

by

Ioanna Dionysiou


  • 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


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


System Security

  • How can system security be achieved?

    • Authorization

    • Authentication

    • Auditing

    • Secure communication


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?


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


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


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?


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


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


MOOSE Architecture(Meta Object Operating System Environment)


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


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


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


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


Object Registry(MOM Components)

Main Function : bookkeeping information associated with each object component

Local identifier of the object component

Miscellaneous information

Component type


How can the object registry be used?

Object Registry – An example(MOM Components)

Component TypeMisc

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?


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?


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


Methods – An example(MOM Components)

msg

Method

interface m1

Method

arbiter m1

Method

body m1


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


Component PrivilegeTicket

Method_1 Lock a

Method_2 Key b

Object Access Control List(MOM Components)

Method_1 has a Lock privilege associated with ticket a.


MOM Authorization Scheme

  • Object Access Control Lists (OACLs)

  • Message Filters

  • Messages and Tickets


o1

t1

Msg.

with

Ticket t1

o2

t1

Ticket-Based Scheme


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


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


Object hierarchy

IS

important

An object can intervene and deny access

Refined Authorization Model Semantics

A

B

C


Refined Authorization Model Semantics

  • Object hierarchy taken into account

  • Message delegation (authorization of message at each passing object in the hierarchy)

    HOW?


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


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


ad
  • Login