Chapter 14: Protection

 Goals of Protection
 Principles of Protection
 Domain of Protection

Chapter 14: Protection 


Access Matrix
Implementation of Access Matrix
 Access Control
 Revocation of Access Rights
 Capability-Based Systems
 Language-Based Protection

Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.2 Silberschatz, Galvin and Gagne ©2013

Objectives Goals of Protection

 Discuss the goals and principles of protection in a modern  In one protection model, computer consists of a collection of
computer system objects, hardware or software
 Explain how protection domains combined with an access  Each object has a unique name and can be accessed through
matrix are used to specify the resources a process may a well-defined set of operations
access  Protection problem - ensure that each object is accessed
 Examine capability and language-based protection systems correctly and only by those processes that are allowed to do so

Operating System Concepts – 9th Edition 14.3 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.4 Silberschatz, Galvin and Gagne ©2013
 Principles of Protection Principles of Protection (Cont.)
 Guiding principle – principle of least privilege  Must consider “grain” aspect
 Programs, users and systems should be given just  Rough-grained privilege management easier, simpler,
enough privileges to perform their tasks but least privilege now done in large chunks
 Limits damage if entity has a bug, gets abused  For example, traditional Unix processes either have
 Can be static (during life of system, during life of abilities of the associated user, or of root
process)  Fine-grained management more complex, more
 Or dynamic (changed by process as needed) – domain overhead, but more protective
switching, privilege escalation  File ACL lists, RBAC
 “Need to know” a similar concept regarding access to  Domain can be user, process, procedure
data

Operating System Concepts – 9th Edition 14.5 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.6 Silberschatz, Galvin and Gagne ©2013

Domain Structure Domain Implementation (UNIX)

 Domain = user-id
 Access-right = <object-name, rights-set>
where rights-set is a subset of all valid operations that can  Domain switch accomplished via file system
be performed on the object  Each file has associated with it a domain bit (setuid bit)
 Domain = set of access-rights  When file is executed and setuid = on, then user-id is
set to owner of the file being executed
 When execution completes user-id is reset
 Domain switch accomplished via passwords
 su command temporarily switches to another user’s
domain when other domain’s password provided
 Domain switching via commands
 sudo command prefix executes specified command in
another domain (if original domain has privilege or
password given)

Operating System Concepts – 9th Edition 14.7 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.8 Silberschatz, Galvin and Gagne ©2013
 Domain Implementation (MULTICS) Multics Benefits and Limits
 Let Di and Dj be any two domain rings
 Ring / hierarchical structure provided more than the basic
 If j < I  Di  Dj kernel / user or root / normal user design
 Fairly complex -> more overhead
 But does not allow strict need-to-know
 Object accessible in Dj but not in Di, then j must be < i
 But then every segment accessible in Di also
accessible in Dj

Operating System Concepts – 9th Edition 14.9 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.10 Silberschatz, Galvin and Gagne ©2013

Access Matrix Use of Access Matrix

 View protection as a matrix (access matrix)  If a process in Domain Di tries to do “op” on object Oj, then
 Rows represent domains “op” must be in the access matrix

 Columns represent objects  User who creates object can define access column for that
object
 Access(i, j) is the set of operations that a process
executing in Domaini can invoke on Objectj  Can be expanded to dynamic protection
 Operations to add, delete access rights
 Special access rights:
 owner of Oi
 copy op from Oi to Oj (denoted by “*”)
 control – Di can modify Dj access rights
 transfer – switch from domain Di to Dj
 Copy and Owner applicable to an object
 Control applicable to domain object

Operating System Concepts – 9th Edition 14.11 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.12 Silberschatz, Galvin and Gagne ©2013
 Use of Access Matrix (Cont.) Access Matrix of Figure A with Domains as Objects

 Access matrix design separates mechanism from policy

 Mechanism
 Operating system provides access-matrix + rules
 If ensures that the matrix is only manipulated by
authorized agents and that rules are strictly enforced
 Policy
 User dictates policy
 Who can access what object and in what mode
 But doesn’t solve the general confinement problem

Operating System Concepts – 9th Edition 14.13 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.14 Silberschatz, Galvin and Gagne ©2013

Access Matrix with Copy Rights Access Matrix With Owner Rights

Operating System Concepts – 9th Edition 14.15 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.16 Silberschatz, Galvin and Gagne ©2013
 Modified Access Matrix of Figure B Implementation of Access Matrix

 Generally, a sparse matrix

 Option 1 – Global table
 Store ordered triples <domain, object,
rights-set> in table
 A requested operation M on object Oj within domain
Di -> search table for < Di, Oj, Rk >
 with M ∈ Rk
 But table could be large -> won’t fit in main memory
 Difficult to group objects (consider an object that all
domains can read)

Operating System Concepts – 9th Edition 14.17 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.18 Silberschatz, Galvin and Gagne ©2013

Implementation of Access Matrix (Cont.) Implementation of Access Matrix (Cont.)

 Option 2 – Access lists for objects

 Each column = Access-control list for one object
 Each column implemented as an access list for one Defines who can perform what operation
object
Domain 1 = Read, Write
 Resulting per-object list consists of ordered pairs
Domain 2 = Read
<domain, rights-set> defining all domains with Domain 3 = Read
non-empty set of access rights for the object
 Easily extended to contain default set -> If M ∈ default  Each Row = Capability List (like a key)
set, also allow access For each domain, what operations allowed on what objects
Object F1 – Read
Object F4 – Read, Write, Execute
Object F5 – Read, Write, Delete, Copy

Operating System Concepts – 9th Edition 14.19 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.20 Silberschatz, Galvin and Gagne ©2013
 Implementation of Access Matrix (Cont.) Implementation of Access Matrix (Cont.)
 Option 3 – Capability list for domains  Option 4 – Lock-key
 Instead of object-based, list is domain based  Compromise between access lists and capability lists
 Capability list for domain is list of objects together with operations  Each object has list of unique bit patterns, called locks
allows on them
 Each domain as list of unique bit patterns called keys
 Object represented by its name or address, called a capability
 Process in a domain can only access object if domain
 Execute operation M on object Oj, process requests operation and
specifies capability as parameter
has key that matches one of the locks
 Possession of capability means access is allowed
 Capability list associated with domain but never directly accessible
by domain
 Rather, protected object, maintained by OS and accessed
indirectly
 Like a “secure pointer”
 Idea can be extended up to applications

Operating System Concepts – 9th Edition 14.21 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.22 Silberschatz, Galvin and Gagne ©2013

Comparison of Implementations Comparison of Implementations (Cont.)

 Many trade-offs to consider  Most systems use combination of access lists and
 Global table is simple, but can be large capabilities
 Access lists correspond to needs of users  First access to an object -> access list searched
 Determining set of access rights for domain non-  If allowed, capability created and attached to
localized so difficult process
 Every access to an object must be checked – Additional accesses need not be checked
– Many objects and access rights -> slow  After last access, capability destroyed
 Capability lists useful for localizing information for a given  Consider file system with ACLs per file
process
 But revocation capabilities can be inefficient
 Lock-key effective and flexible, keys can be passed freely
from domain to domain, easy revocation

Operating System Concepts – 9th Edition 14.23 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.24 Silberschatz, Galvin and Gagne ©2013
 Access Control Revocation of Access Rights

 Protection can be applied to non-file  Various options to remove the access right of a domain to an
resources object
 Oracle Solaris 10 provides role-  Immediate vs. delayed
based access control (RBAC) to  Selective vs. general
implement least privilege
 Partial vs. total
 Privilege is right to execute
 Temporary vs. permanent
system call or use an option
within a system call  Access List – Delete access rights from access list
 Can be assigned to processes  Simple – search access list and remove entry
 Users assigned roles granting  Immediate, general or selective, total or partial,
access to privileges and permanent or temporary
programs
 Enable role via password to
gain its privileges
 Similar to access matrix

Operating System Concepts – 9th Edition 14.25 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.26 Silberschatz, Galvin and Gagne ©2013

Revocation of Access Rights (Cont.) Capability-Based Systems

 Capability List – Scheme required to locate capability in the  Hydra

system before capability can be revoked  Fixed set of access rights known to and interpreted by the system
 Reacquisition – periodic delete, with require and denial if  i.e. read, write, or execute each memory segment
revoked  User can declare other auxiliary rights and register those with
 Back-pointers – set of pointers from each object to all protection system
capabilities of that object (Multics)  Accessing process must hold capability and know name of
operation
 Indirection – capability points to global table entry which points
 Rights amplification allowed by trustworthy procedures for a
to object – delete entry from global table, not selective (CAL)
specific type
 Keys – unique bits associated with capability, generated when  Interpretation of user-defined rights performed solely by user's
capability created program; system provides access protection for use of these rights
 Master key associated with object, key matches master key  Operations on objects defined procedurally – procedures are
for access objects accessed indirectly by capabilities
 Revocation – create new master key  Solves the problem of mutually suspicious subsystems

 Policy decision of who can create and modify keys – object  Includes library of prewritten security routines
owner or others?

Operating System Concepts – 9th Edition 14.27 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.28 Silberschatz, Galvin and Gagne ©2013
 Capability-Based Systems (Cont.) Language-Based Protection
 Cambridge CAP System  Specification of protection in a programming language
 Simpler but powerful allows the high-level description of policies for the
 Data capability - provides standard read, write, execute allocation and use of resources
of individual storage segments associated with object –  Language implementation can provide software for
implemented in microcode protection enforcement when automatic hardware-
 Software capability -interpretation left to the supported checking is unavailable
subsystem, through its protected procedures  Interpret protection specifications to generate calls on
 Only has access to its own subsystem whatever protection system is provided by the hardware
and the operating system
 Programmers must learn principles and techniques
of protection

Operating System Concepts – 9th Edition 14.29 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.30 Silberschatz, Galvin and Gagne ©2013

Protection in Java 2 Stack Inspection

 Protection is handled by the Java Virtual Machine (JVM)

 A class is assigned a protection domain when it is loaded by
the JVM
 The protection domain indicates what operations the class
can (and cannot) perform
 If a library method is invoked that performs a privileged
operation, the stack is inspected to ensure the operation can
be performed by the library
 Generally, Java’s load-time and run-time checks enforce type
safety
 Classes effectively encapsulate and protect data and
methods from other classes

Operating System Concepts – 9th Edition 14.31 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 14.32 Silberschatz, Galvin and Gagne ©2013
 End of Chapter 14

Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013