Transcript Chap 14: Protection

Cosc 4740
Chapter 13:
Protection
Goals of Protection
• Operating system consists of a collection of
objects, hardware or software
• Each object has a unique name and can be
accessed through a well-defined set of operations.
• Protection problem - ensure that each object is
accessed correctly and only by those processes
that are allowed to do so.
Principles of Protection
• Guiding principle – principle of least privilege
– Programs, users and systems should be given just
enough privileges to perform their tasks
– Limits damage if entity has a bug, gets abused
• Can be static (during life of system, during life of
process)
• Or dynamic (changed by process as needed) – domain
switching, privilege escalation
– “Need to know” a similar concept regarding access
to data
Principles of Protection (2)
• Must consider “grain” aspect
– Rough-grained privilege management easier,
simpler, but least privilege now done in large
chunks
• For example, traditional Unix processes either have
abilities of the associated user, or of root
– Fine-grained management more complex, more
overhead, but more protective
• File ACL lists, RBAC
• Domain can be user, process, procedure
Domain Structure
• Access-right = <object-name, rights-set>
where rights-set is a subset of all valid
operations that can be performed on the
object.
• Domain = set of access-rights
Hardware example
• Dual-mode operation
– monitor (kernel) mode vs user mode
– Privileged instructions can only executed while
in kernel mode.
• If used implemented by hardware and used by O/S
becomes the base of a protection scheme between
users and the O/S.
• Does not protect between two user processes.
Domain Implementation (UNIX)
• System consists of 2 domains:
– User (really many domains, but generalized to user)
– Supervisor (normally called root in UNIX)
• UNIX
– Domain = user-id
– Domain switch accomplished via file system.
• Each file has associated with it a domain bit (setuid bit).
• 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 also accomplished by a command: su or
sudo
Domain Implementation
(MULTICS)
• Let Di and Dj be any two domain rings
• If j < I  Di  Dj
Multics Benefits and Limits
• Ring / hierarchical structure provided more than the
basic 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
Access Matrix
• View protection as a matrix (access matrix)
• Rows represent domains
• Columns represent objects
• Access(i, j) is the set of operations that a process
executing in Domaini can invoke on Objectj
Access Matrix
Use of Access Matrix
• If a process in Domain Di tries to do “op” on
object Oj, then “op” must be in the access matrix.
– User who creates object can define access column for
that object
• Can be expanded to dynamic protection.
– Operations to add, delete access rights.
– Special access rights:
•
•
•
•
owner of Oi
copy op from Oi to Oj
control – Di can modify Dj access rights
transfer – switch from domain Di to Dj
Use of Access Matrix (Cont.)
• 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
Access Matrix of Figure A
with Domains as Objects
Access Matrix with Copy Rights
Access Matrix With Owner
Rights
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)
• Option 2 – Access lists for objects
– Each column implemented as an access list for one object
– Resulting per-object list consists of ordered pairs < domain, rights-set >
defining all domains with non-empty set of access rights for the object
– Easily extended to contain default set -> If M ∈ default set, also allow access
Implementation of Access Matrix
(cont)
• Each column = Access-control list for one
object
Defines who can perform what operation.
Domain 1 = Read, Write
Domain 2 = Read
Domain 3 = Read

• Each Row = Capability List (like a key)
Fore each domain, what operations allowed
on what objects.
Object 1 – Read
Object 4 – Read, Write, Execute
Object 5 – Read, Write, Delete, Copy
Implementation of Access Matrix
(Cont.)
• Option 3 – Capability list for domains
– Instead of object-based, list is domain based
– Capability list for domain is list of objects together with
operations allows on them
– Object represented by its name or address, called a capability
– Execute operation M on object Oj, process requests operation and
specifies capability as parameter
• 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
Implementation of Access Matrix
(Cont.)
• Option 4 – Lock-key
– Compromise between access lists and
capability lists
– Each object has list of unique bit patterns,
called locks
– Each domain as list of unique bit patterns called
keys
– Process in a domain can only access object if
domain has key that matches one of the locks
Comparison of Implementations
• Many trade-offs to consider
– Global table is simple, but can be large
– Access lists correspond to needs of users
• Determining set of access rights for domain non-localized so
difficult
• Every access to an object must be checked
– Many objects and access rights -> slow
– Capability lists useful for localizing information for a
given process
• But revocation capabilities can be inefficient
– Lock-key effective and flexible, keys can be passed
freely from domain to domain, easy revocation
Comparison of Implementations (2)
• Most systems use combination of access lists
and capabilities
– First access to an object -> access list searched
• If allowed, capability created and attached to process
– Additional accesses need not be checked
• After last access, capability destroyed
• Consider file system with ACLs per file
Access Control
• Protection can be applied to non-file
resources
• Solaris 10 provides role-based access
control to implement least privilege
– Privilege is right to execute system call or use
an option within a system call
– Can be assigned to processes
– Users assigned roles granting access to
privileges and programs
Role-based Access Control
• in Solaris 10
Revocation of Access Rights
• Various options to remove the access right
of a domain to an object
– Immediate vs. delayed
– Selective vs. general
– Partial vs. total
– Temporary vs. permanent
• Access List – Delete access rights from access list.
– Simple - Search access list and remove entry
– Immediate, general or selective, total or partial,
permanent or temporary
Revocation of Access Rights
• Capability List – Scheme required to locate capability in
the system before capability can be revoked
– Reacquisition – periodic delete, with require and denial if
revoked
– Back-pointers – set of pointers from each object to all
capabilities of that object (Multics)
– Indirection – capability points to global table entry which
points to object – delete entry from global table, not selective
(CAL)
– Keys – unique bits associated with capability, generated
when capability created
• Master key associated with object, key matches master key for access
• Revocation – create new master key
• Policy decision of who can create and modify keys – object owner or
others?
Capability-Based Systems
• Hydra
– Fixed set of access rights known to and interpreted by the system.
• i.e. read, write, or execute each memory segment
• User can declare other auxiliary rights and register those with protection
system
• Accessing process must hold capability and know name of operation
• Rights amplification allowed by trustworthy procedures for a specific
type
– Interpretation of user-defined rights performed solely by user's
program; system provides access protection for use of these rights
– Operations on objects defined procedurally – procedures are
objects accessed indirectly by capabilities
– Solves the problem of mutually suspicious subsystems
– Includes library of prewritten security routines
Capability-Based Systems (2)
• Cambridge CAP System
– Simpler but powerful
– Data capability - provides standard read, write,
execute of individual storage segments associated
with object – implemented in microcode
– Software capability -interpretation left to the
subsystem, through its protected procedures
• Only has access to its own subsystem
• Programmers must learn principles and techniques of
protection
Language-Based Protection
• Specification of protection in a programming
language allows the high-level description of
policies for the allocation and use of resources.
• Language implementation can provide software
for protection enforcement when automatic
hardware-supported checking is unavailable.
• Interpret protection specifications to generate calls
on whatever protection system is provided by the
hardware and the operating system.
Protection in Java 2
• 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.
Stack Inspection
Q&A