Protection Models

Yeong-Tay Timothy Sun

September 27, 2011

1Dennis Kafura – CS5204 – Operating Systems

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 progressionSupports 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.