1 / 25

The Extended Schematic Protection Model (ESPM)

The Extended Schematic Protection Model (ESPM). Ravi Sandhu Laboratory for Information Security Technology George Mason University www.list.gmu.edu sandhu@gmu.edu. Recap. HRU has undecidable safety under very weak assumptions Bi-conditional monotonic Take-Grant and variations

kim
Télécharger la présentation

The Extended Schematic Protection Model (ESPM)

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Extended Schematic Protection Model(ESPM) Ravi Sandhu Laboratory for Information Security Technology George Mason University www.list.gmu.edu sandhu@gmu.edu

  2. Recap • HRU has undecidable safety under very weak assumptions • Bi-conditional monotonic • Take-Grant and variations • Efficiently decidable safety • Unexpected aggregate policy • Schematic protection model (SPM) • Useful demarcation of efficiently decidable safety • Decidable for acyclic attenuating schemes • polynomial in size of initial state • exponential in number of types (for dense cc relation) • open question: acyclic non-attenuating • Undecidable for cyclic schemes • Copy flag and demand operation turn out to be redundant • SPM can simulate Bell LaPadula multilevel security

  3. SPM creation

  4. ESPM joint creation

  5. Monotonic HRU command

  6. ESPM simulation • Parameter list generation • Marshall parameter set of size Ji • Validating the conditional • Simulating the HRU command body • Simulating creates • Unconditional create with alive right, so X/alive  dom(X) is required for X to participate in any command • Simulating enters • straightforward

  7. ESPM types • p: proxy entity type • Px/r  dom(Py) for Px, Py of type p in ESPM system iff r  [Py,Px] in HRU system • {aj | j=1…Jmax}: agent types • Represent ESPM proxy entity in jth parameter of HRU command • {vi | i=1…I}: validator types • Represent a collection of Ji entities in instance of HRU commandi • Created by joint creation with agent types as parents • {tki | k=1…Ki, i=1…I}: term types • Simulate truth value of each term in each HRU command • {cmi | m=1…Mi, i=1…I}: create types • Simulate creates for each HRU command • {eni | n=1…Ni, i=1…I}: enter types • Simulate enters for each HRU command

  8. ESPM creation

  9. ESPM attenuating loops If type(ui) = type(v) Except that one such parent can have attenuating rule crpj(u1, u2, …, uN, v) = pj/R2j c/R1j crc(u1, u2, …, uN, v) = pj/R3j c/R4j so R1j R2j and R3j R2j and R4j R1j

  10. ESPM unfolded state

  11. ESPM unfolded state

  12. ESPM safety analysis • exponential in types (like SPM) • exponential in size of initial state (unlike SPM)

  13. ESPM safety analysis

  14. Expressive power of SPM and ESPM • both are monotonic • ESPM is equivalent to monotonic HRU • HRU can simulate ESPM • ESPM can simulate HRU • ESPM with double-parent creation is equivalent to ESPM • ESPM is at least as expressive as SPM • ESPM can simulate SPM trivially • it turns out that SPM is less expressive than ESPM (and thereby less expressive than monotonic) HRU

  15. Monotonic access graph model • nodes are strongly typed • type of a node cannot change • edges are strongly typed • type of an edge cannot change • graph operations • initial state operations • node operations • multi-parent • creates new edges from each parent to child • edge operations • cannot create new nodes • must be monotonic (edges cannot be removed)

  16. Simulation: scheme B simulates scheme A

  17. Scheme A has double-parent creation

  18. Double-parent creation in scheme A

  19. Double-parent creation in scheme A

  20. Failed simulation in scheme B with single-parent creation and identical initial state

  21. Failed simulation in scheme B with single-parent creation and arbitrary initial state

  22. Failed simulation in scheme B with single-parent creation and arbitrary initial state

  23. Failed simulation in scheme B with single-parent creation and arbitrary initial state

  24. Multi-parent creation does not add power in non-monotonic systems

  25. Multi-parent creation • Adds power to monotonic models • Perhaps should be viewed as a non-monotonic binding operation

More Related