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

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 2

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

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

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)

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

Access Matrix (2)

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

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

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

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

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

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

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

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

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

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

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

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.