Protection Models
Yeong-Tay Timothy Sun
September 27, 2011
Dennis Kafura – CS5204 – Operating Systems
1
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
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.