Outline
• Announcements
V22.0202-001
Computer Systems Organization II (Honors)
– Lab 5 demos today and tomorrow
– Lab 6 due back on May 6th
– Final exam on May 9th, 2:00 – 3:50pm, 101 WWH
(Introductory Operating Systems)
• Review on May 6th
• Secondary storage structure (cont’d)
Lecture 20
Secondary Storage Structure (cont’d)
Protection
– Reliability concerns
• Protection
–
–
–
–
April 24, 2002
Goals of protection
Domain of protection
Access matrix
Access rights and capabilities
[ Silberschatz/Galvin/Gagne: Section 14.7, Chapter 18]
4/24/2002
2
(Review) Reliability Concerns - 1
RAID Level 5: Rotating Block-Interleaved Parity
• Recovery from disk failures involving large amounts of information
• RAID Level 4 takes a performance hit on small, random requests
– backups are expensive but the obvious solution
– All requests access the parity drive, which becomes a bottleneck
• Solution: Distribute the parity information
RAID: Redundant Array of Inexpensive Disks
• Level 1: Mirroring
– No loss in reliability
– Good performance properties
– maintains a copy of each disk
– wasteful and expensive
Disk 1
• Level 3: Byte-level striping with parity
Disk 2
Disk 3
Disk 4
Disk 5
– Use k disks: k-1 for storage, one for parity
– if any one disk fails, its contents can be recomputed
– disadvantage: each disk operation requires access to all disks
• Level 4: Block-level striping with parity
– a block resides on a single disk
– writes involve 2 disks: data and parity
4/24/2002
3
4/24/2002
4
Reliability Concerns - 2
• Recovery from disk failures where only a portion of the
information is lost
– data-transfers may result in
• success
• partial failure:
• total failure:
the destination sector contains incorrect information
the destination is unchanged
Protection
• The object of stable storage is to recover from partial failures
– write multiple copies of each block
• typically two
– a write is complete when all copies are written
– to recover from a failure
• after writing, check all blocks
• if a detectable error exists, then use the error-free value in all copies
• if not, the "value" of the block is that of the last (second) copy
4/24/2002
5
Protection
Domain of Protection
• The overall need
• Components
– initially caused by the explosion in multiprogramming
– Logical processes
– Classes of logical objects that processes can access in various ways
• recently by the explosion in networking
– needed multiple co-existent processes not to encroach/interfere
• e.g. files, directories, devices
• accidentally or maliciously ...
• into unwanted regions
– Each object class has a set of rights
• e.g. read, write, delete
Solution:
• Define specific domains that specify the privileges of a
user/process/procedure to access system resources
• A process at any given time
– is in a particular domain
– inherits all of its privileges
– For each resource, what are the operations that the process can do
• Domains are the granularity at which privileges are specified
• Resources: files, memory segments/pages, printer, …
• Provide mechanisms for enforcing these privileges
– Hardware: Protection faults, privileged instructions, exceptions
– Software: System calls
4/24/2002
7
4/24/2002
8
What is a Domain?
Examples
• Formally, a domain is a set of access rights
• Dual-mode model of operating system execution
– an access right is a pair: <object, rights>
– Two domains: system (monitor) and user
– System domain has complete rights
– User domain cannot execute privileged instructions
• Example could be <payroll-file, read-only>
• A process can only be in one particular domain at any given time
• Unix
– Association can be …
– … static: need OS mechanisms to modify access rights
– or dynamic: need OS mechanisms to switch domains
– Three kinds of domains: users, groups, “other”
– Access rights are specified for each such domain
• E.g., chmod operations for setting file access rights
– Switching the domain corresponds to changing the user identification or
group identification temporarily
• Domains can
– contain each other
– be non-overlapping
– change over time, i.e. can be modified
4/24/2002
9
4/24/2002
Access Matrices
Mechanism vs. Policy
• Used to describe domains
• The OS supports means of specifying and enforcing preferred access
patterns via the access matrix and hence supports the mechanism
• The actual decisions are entries in the matrix and denote policy
– Each row is a domain
– Each column is an object
– Entry (i, j) indicates the privileges associated with domain i to access
object j
• Typically, the owner of an object determines the corresponding
privileges and hence entries in the appropriate column
• Example
D1
D2
D3
D4
4/24/2002
F1
r
F2
F3
r
r
x
rw
10
printer
pr
r
11
4/24/2002
12
Implementing Access Matrices
Implementing Access Matrices (contd.)
• Implementing the whole matrix
• By rows
– Allows very fast direct access
– Extremely space inefficient
– Each domain has a capability list
• What privileges does this domain have for each kind of object
– Easily accessed: indexed by "object"
• most objects are accessed by only a few domains
• matrices are very sparse
• These lists themselves
– can be viewed as special objects
• By columns
• Typically, only an OS-state induced domain can change things in them
– Each object has an access list
– can also be supported in hardware and tagged as such, to distinguish it
– segmentation is a good way of realizing this
• Which domains have what privileges
– Advantages
• Easily extensible
• e.g. to add new domains that can access a given object
– Used in condensed form in Unix
4/24/2002
13
4/24/2002
14
Lock-Key Mechanisms
Access Matrix Implementations In Practice
• Compromise between access lists and capability lists
• Most systems use a mixture of
– Each object has a unique list of bit patterns called locks
– Domain has a list of bit patterns called keys
– To access an object, the domain must have a key that matches one of its
locks
– access lists
– capability lists
• For example, in Unix, we can view
– File permissions as access lists
– File handles (FIDs) as capabilities
– OS calls such as open
• Example: Unix
– Domain is decided by effective UID, GID
• setuid bit permits switching of domains (can become root if not careful)
• Check that the process has the appropriate permissions
– Objects are files or directories
– lock is the 9-bit access code
– Enforced by the system call mechanism
– Requires comparing against the permissions associated with the file
• Return a capability, the file handle
• This capability can be used in subsequent system calls to avoid repeated
protection checks
• 3 bits for each of three domains: owner, group, other
• Rights: read, write, execute (interpreted as search, create, use for directories)
– E.g., rwxrw-r--
– key is effective UID and effective GID
• Normalized with respect to the owner and group of the file/directory
4/24/2002
15
4/24/2002
16
Another Example: MULTICS
MULTICS Protection Scheme (cont’d)
• Protection domains are hierarchically arranged and are organized such
that Dj is a subset of Di whenever i > j
• Significant weaknesses
– These domains are called rings
– D0 has the most privileges
– As a process moves from an “outer" ring to an “inner" one
• it strictly gains new privileges while maintaining all of its old
• contravenes the need to know principle
• an important rule in designing protection policies
10
– Cannot create partially overlapping domains
• MULTICS has a segmented address space
– Also, relatively heavyweight
– Each segment is associated with one of the rings and a set of permissions
– A process in ring Di can only access segments in rings Dj (j ≥ i)
• Processes switch domains to change access privileges
Each segment also has associated with it
– An access bracket (b1, b2): Call is allowed if b1 ≤ i ≤ b2, else traps
• A trapped call is permitted to proceed if i ≤ b1
– A limit (b3) and a list of gates defining valid entry points
• Trapped calls where i ≥ b2 are allowed only to a gate and if i ≤ b3
4/24/2002
17
4/24/2002
18
Access Matrices: More General Operations
Language-based Protection: Rationale
• In general, also want some way of
• Protection solutions discussed so far require involvement of OS kernel
– Dynamically changing domains
– To validate access rights or capabilities at run time
– Tend to be high overhead
– Are inflexible in the objects and operations being protected
• Treat domains also as objects
• Rights associated with this object indicate whether or not a switch is allowed
– Increasing privileges (capabilities) and passing them on
– See Section 18.3 for details
• System-defined functions: e.g., file operations
– Require hardware support for efficiency
• E.g., virtual-memory page protection
• Not generally applicable
• Revocation of access rights
– Several dimensions: immediate vs. delayed, selective (w.r.t. domain
members), partial (w.r.t. rights on object), temporary vs. permanent
–
• Current-day OSes need additional flexibility
– To protect arbitrary (user-defined) objects and operations
Access Lists: Just scan the list and modify
• E.g., a server might want to restrict access to certain services
• Does not work as well when there are too many objects
– Need these checks to be performed efficiently
– Capabilities: Harder problem, since they are distributed to members
• Require periodic reacquisition of capabilities
• Capabilities point to actual object via an indirect “object table”
4/24/2002
• Solutions involve language features and their trusted implementation
19
4/24/2002
20
Next Lecture
• Advanced Topic: Language-based protection
– rationale
– language-based protection mechanisms
• examples: software-fault isolation (SFI), type safety, proof-carrying code
• pros and cons
– secure-services using language-based protection
• capabilities, stack introspection, namespace management
Reading
• Silberschatz/Galvin/Gagne: Section 18.7
4/24/2002
21