Exploring SecPAL: A Declarative Security Policy Assertion Language for Distributed Systems

1. SecPAL Presented by Daniel Pechulis CS5204 – Operating Systems

2. Overview • What and why • SecPAL Specifics • Logic Examples • Implementation Example CS5204 – Operating Systems

3. Introduction • SecPAL – Security Policy Assertion Language • Designed by Microsoft Research • Declarative authorization language • Designed for distributed systems • Simplicity, expressiveness, and efficiency CS5204 – Operating Systems

4. Distributed Systems CS5204 – Operating Systems

5. 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 CS5204 – Operating Systems

6. 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 CS5204 – Operating Systems

7. 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 CS5204 – Operating Systems

8. 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 CS5204 – Operating Systems

9. Language Details • Assertions • Basic format: ‘A says fact if fact1,…,factn, c’ • A is the issuer • fact1,…,factn are theconditional facts • cis 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 CS5204 – Operating Systems

10. Language Details (con’t) • Semantics • 3 basic rules • cond – ‘say’ keyword • can say – denotesdelegation, ceding control to another entity for the decision • can act as – asserts that all rules applying to one entity also apply to another CS5204 – Operating Systems

11. 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 CS5204 – Operating Systems

12. 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 CS5204 – Operating Systems

13. Grid Example (Step 2) • Cluster must authenticate and validate the incoming request • Suppose the following local Cluster assertions • ‘Cluster says STS can say0x 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 dbgrepif x is a researcher’ • Cluster grants the right to execute dbgrep if requester is a certified researcher CS5204 – Operating Systems

14. Grid Example (Step 3) • FileSerververifies action and proceeds • Suppose the following local FileServer assertion • ‘FileServersays x can say∞y can read file ifx can read dir, file contains dir,markedConfidential(file) ≠ Yes’ • x = Alice, y = Cluster • say∞ allows for re-delegation, say0 does not CS5204 – Operating Systems

15. 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, ‘FileServersays Node can act as Cluster’ • ‘can act as’ gives every Cluster right to Node CS5204 – Operating Systems

16. 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 CS5204 – Operating Systems

17. GridFTP.NET Implementation CS5204 – Operating Systems

18. GridFTP.NET Results • Successfully implemented most requirements • All use cases satisfied • Some requirements require further study • Minimal performance hit (vsgridmap) • 10M file – 4.2% • 100M file – 1.0% CS5204 – Operating Systems

19. Questions? CS5204 – Operating Systems

20. 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. CS5204 – Operating Systems