Protection Models

1. Protection Models Yeong-Tay Timothy Sun September 27, 2011 Dennis Kafura – CS5204 – Operating Systems

2. Agenda • What is Protection (and why do we need it?) • A Simple Message Passing System • Collaborative Access Control Models • Access Matrix • Role-Based Access Control (RBAC) • Task-Based Access Control (TBAC) • Team-Based Access Control (TBAC) • Bell-LaPadula • Lock and Key • Spatial Access Control (SPACE) • Context-Aware Access Control • Conclusion Dennis Kafura – CS5204 – Operating Systems

3. What is Protection? Protection governs access to shared system assets Unsolicited access may be malicious or simply unintentional Having different protections in different system contexts is a core concept

4. A Simple Message Passing System • Primitive Message System consists of isolated processes • Processes encapsulate their own collection of objects • Inter-process communication consists of passing message back and forth; message IDs cannot be forged • Communication protocols become complicated when multiple processes are involved • Cannot force a process to do anything, or to destroy it

5. Implications for Access Control Models? • Should be applied and enforced at a distributed level • Should be generic and configurable (expressive) • Should support both fine and coarse granularity • Should be usable (transparent = good) • Should be easy to summarize (manageable) • Should support dynamic policies • Should perform reasonably (scalable)

6. Collaborative Access Control Models(Access Matrix) • Object system has a subject-object relationship • Different domains have different access rights

7. Access Matrix (2)

8. Access Matrix (3) • Both implementations (ACLs, C-Lists) have disadvantages, dynamic changes to access rights not well-supported • Difficult to adapt to more complex schemes (competency, least privilege, etc.) without additional system context • Ownership may be subject to other system constraints

9. Role-Based Access Control • Permissions assigned to roles rather than individual users • A role models a job function • Users can be assigned from one role to another

10. Role-Based Access Control (2) • Early implementations not dynamic in their assignment of roles, did not account for context (passive vs. active) • Early implementations did not support role assignments to specific object instances

11. Task-Based Access Control (TBAC) • Domains contain task-based contextual information • Access control changes dynamically w/ task progression • Supports type-based, instance, usage-based access over RBAC

12. Task-Based Access Control (2) • Context awareness remains tied to activities, tasks, workflow progression • JIT permission assignments could lead to race conditions • Mainly used to augment other access control models

13. Team-Based Access Control (TMAC, C-TMAC) • Access rights associated with groups of users • User context, object context • Offers fine-grained control

14. Team-Based Access Control (2) • Existing implementations are underdeveloped • Lacks self-adminstration capabilities of models like access matrices • Needs more context-awareness • Suitability for certain tasks is unclear

15. Bell-LaPadula • Intended to control the proliferation of data • Uses access matrix for level clearance • ★ Property – information can only become more secure, not less

16. Lock and Key • Similar but different from C-List • Involves Keys and Locks • Keys can change hands • Key doesn’t tell you capabilities it “unlocks” until it is used

17. Spatial Access Control (SAC) • Transparent security mechanisms • Access governed by credentials • Does not allow for fine-grained control • Difficult to apply

18. Context-Aware Access Control • Extends RBAC w/ environmental roles • Roles capture environment state • Activated based on environment conditions • Ubiquitous computing

19. Conclusion There are many things to consider when choosing a protection scheme for a system. No single protection model can address all of these issues but some excel at areas where others do not.