SecPAL

Presented by Daniel Pechulis

CS5204 – Operating Systems 1

SecPAL

CS5204 – Operating Systems

Overview

What and why

SecPAL Specifics

Logic Examples

Implementation Example

2

SecPAL

CS5204 – Operating Systems

Introduction

SecPAL – Security Policy Assertion Language Designed by Microsoft Research Declarative authorization language Designed for distributed systems Simplicity, expressiveness, and efficiency

3

SecPAL

CS5204 – Operating Systems

Distributed Systems

4

SecPAL

CS5204 – Operating Systems

Distributed Systems

Frequent ad hoc collaborations No centralized entity to grant authorization

No pre-established trust No certificates or guarantees

Separated authorization policies Different rules, different needs

5

SecPAL

CS5204 – Operating Systems

Existing Solutions

XrML – eXtensible Rights Markup Language XACML – eXtensible Access Control Markup

Language SPKI/SDCI – Simple Public Key Infrastructure /

Simple Distributed Security Infrastructure

Not widely adopted, possibly due to poor usability

6

SecPAL

CS5204 – Operating Systems

Design Considerations

Expressiveness Delegation of authority – essential in distributed system Domain specific constraints – promote flexibility Negation – useful, but must be controlled

Clear, readable syntax XML – too verbose, poor usability Logic – difficult to follow

7

SecPAL

CS5204 – Operating Systems

Design Considerations

Succinct, unambiguous semantics Existing solutions do not always terminate or decide SecPAL – 3 deduction rules for assertions Managed negation

Effective decision procedures Proven decidable and tractable in polynomial time

through translation to constrained Datalog

Extensibility Can be extended without breaking current functionality

8

SecPAL

CS5204 – Operating Systems

Language Details Assertions

Basic format: ‘A says fact if fact1,…,factn, c’

A is the issuer fact1,…,factn are the conditional facts c is the constraint

Digitally signed by a Security Token Server and sent as tokens

Constraints Can be applied to variables, constants, or built-in

functions Domain includes equality, numerical inequalities, path

constraints, and regular expressions

9

SecPAL

CS5204 – Operating Systems

Language Details (con’t)

Semantics 3 basic rules

cond – ‘say’ keyword can say – denotes delegation, ceding control to another

entity for the decision can act as – asserts that all rules applying to one entity

also apply to another

10

SecPAL

CS5204 – Operating Systems

Grid Example

Simple grid system Interaction between administrative domains with

individual policies Attribute based authorization and delegation

Scenario: User Alice wants to perform data mining on cluster Cluster must fetch file from file server No trust relationship between Alice and Cluster, or

Cluster and File Server

11

SecPAL

CS5204 – Operating Systems

Grid Example (Step 1) Alice requests execution of command: dbgrep /project/data ‘STS says Alice is a researcher’

STS is a trusted security server Identity token issued to validate Alice’s identity

‘FileServer says Alice can read /project’ FileServer asserts Alice the right to read specified folder

‘Alice says Cluster can read /project/data if currentTime() <= 07/09/2006’

Alice delegates to Cluster the right to read the file until the specified date

12

SecPAL

CS5204 – Operating Systems

Grid Example (Step 2)

Cluster must authenticate and validate the incoming request

Suppose the following local Cluster assertions ‘Cluster says STS can say0 x is a researcher’

Cluster defers to STS to determine who is a researcher STS identified Alice as a researcher earlier step

‘Cluster says x can execute dbgrep if x is a researcher’

Cluster grants the right to execute dbgrep if requester is a certified researcher

13

SecPAL

CS5204 – Operating Systems

Grid Example (Step 3)

FileServer verifies action and proceeds Suppose the following local FileServer

assertion ‘FileServer says x can say∞ y can read file if

x can read dir, file contains dir,markedConfidential(file) ≠ Yes’

x = Alice, y = Cluster say∞ allows for re-delegation, say0 does not

14

SecPAL

CS5204 – Operating Systems

Grid Example (Step 4)

Cluster would now send the task to its computation nodes for execution Each Node could receive a delegation assertion from Cluster (remember say∞ )

Or, ‘FileServer says Node can act as Cluster’ ‘can act as’ gives every Cluster right to Node

15

SecPAL

CS5204 – Operating Systems

GridFTP.NET

Multiple access types Attribute based Role based “Role-deny” based Impersonation based Delegation based Capability based

Entities Data owner Resource provider Virtual Organization (VO) Data requester

16

SecPAL

CS5204 – Operating Systems

GridFTP.NET Implementation

17

SecPAL

CS5204 – Operating Systems

GridFTP.NET Results

Successfully implemented most requirements All use cases satisfied Some requirements require further study

Minimal performance hit (vs gridmap) 10M file – 4.2% 100M file – 1.0%

18

SecPAL

CS5204 – Operating Systems 19

Questions?

SecPAL

CS5204 – Operating Systems

References

M. Becker, C. Fournet, A. Gordon, “SecPAL: Design and Semantics of a Decentralized Authorization Language,” Cambridge, UK, 2006. Microsoft Research.

B. Dillaway, “A Unified Approach to Trust, Delegation, and Authorization in Large-Scale Grids,” Redmond, WA, 2006. Microsoft Corporation.

M. Humphery, S. Park, J. Feng, N. Beekwilder, G. Wasson, J. Hogg, B. LaMacchia, B. Dillaway, “Fine-Grained Access Control for GridFTP using SecPAL,” 8th IEEE/ACM International Conference on Grid Computing (Grid 2007), Austin, TX, Sept 19-21, 2007.

20