Operating Systems Lecture Notes

2014 December 2 • Security Mechanisms

---

Outline

System Model

• An object is defined by the set of operations it supports.
  • Every object is distinct from all other objects, its identity.
• One object, the calling object, invokes an operation provided by another object, the called object.
  • The caller and called object are distinct.
• A system is a dynamic set of objects.

Objective

• Characterize the desirable operation invocations between objects.
  • Advanced objective: among objects.
  • This characterization is the security policy.
• Make sure all operation invocations in the system are desirable.

What For?

• Two obvious characterizations:
  1. Nothing is permitted (just say no).
  2. Everything is permitted (just say yes).
• Characterization 1 is simple and useless.
• Characterization 2 is as simple and useful. What's wrong with it?
  • It doesn't map well to peoples' world view.
  • No notions of authorization and access.

Policy and Mechanism

• System objectives:
  • Promote desirable behavior.
  • Prevent undesirable behavior.
• Policy defines desirable and undesirable behavior: the what.
• Mechanism implements promoting and preventing: the how.
• This is a lecture on mechanism.

Access Matrix

• View protection as an access matrix.
  • Rows represent domains.
  • Columns represent objects.
• access(i, j) is the set of operations that a process in domain i can invoke on object j.

Access Matrix Use

• A process in domain i can invoke op on object j if op ∈ access(i, j).
• The creator of object j defines the entries in column j.
  • Statically at column creation time.
  • Dynamically during object lifetime.

Dynamic Rights Assignment

• An access-matrix element has add and remove operations.
• An associated domain: owner of object i.
• Special access rights:
  • Owner of object i.
  • Copy op from object i to object j.
  • Modify domain i access rights.
  • Transfer from domain i to domain j.

Access Matrix Observations

• Mechanism and policy are separate.
  • Mechanisms: the access matrix in use.
  • Policy: what's in the access matrix.
• Access matrices don't solve the general confinement problem.

Domains

• Sets of calling objects may exhibit similar or identical invocation patterns.
• Abstract those patterns into domains.
• Replace calling-object rows with domain rows.
  • N common rows collapse into a single row.
• Associate calling objects with domains.
• The domain-object relation is another object for the access matrix.

Implementation

• A large sparse matrix.
  • Large: all objects × all domains.
  • Sparse: most domains don't care about most objects.

A Matrix Implementation

Implement the access matrix as a sparse matrix.

A list of (domain, object, ops) triples.

Can domain i perform op on object i?

• Is (domain i, object j, R) in the table?
• Is op ∈ R?

Problems: huge, inarticulate.

• What can a domain do? What does an object allow?

ACL Example

• Can domain i perform op on object i?
  • Is (domain i, object j, R) in object j's ACL?
  • Is op ∈ R?
  • Is op ∈ M, the default rights set?

Column-Based Implementation

• Each column implemented as an domain permissions list for an object.
  • Called an capability.
• A compact list of (object, rights) pairs.

Row-Based Implementation

• Each row implemented as an object rights list for a domain.
  • Called a capability
• Can domain i perform op on object i?
  • Is (object j, R) in domain i's capability?
  • Is op ∈ R?

Blob-Based Implementation

• A small number of rights sets per object over all domains.
• Assign each rights set a lock bit pattern.
• An interested domain is assigned one of the locks as a key.
• Can domain i perform op on object i?
  • Is domain i's key k one of object j's locks?
  • Is op in the rights set associated with k?

MULTIX Protection

• MULTIX was a 1970s large-scale OS project.
• A set of pre-defined domains D_i for 0 ≤ i ≤ n.
• Lower indexed rings are more privileged than higher indexed rings.
  • D_i ⊂ D_j when i > j.
  • Ring 0 is most privileged.
• Not only domains, but relations between domains.

MULTIX Illustrated

Unix Protection

• Unix has three protection domains: user, group, and other.
  • Every user is sole occupant of their user domain.
  • Every user is in one of a set of group domains.
    • A user may move among groups in the set, and add and remove group members.
  • Every user is in the other domain.

Unix Protection Objects

• Files are the basic protection objects.
  • Unix tries to make everything look like a file.
• Operations are read, write and execute.
  • Suitably re-interpreted.
• Files are tagged with user (owner) and group domains (one of each).
• Each domain has appropriate read-write-execute permissions set.

Unix Example

Summary

References

• HYDRA: The Kernel of a Multiprocessor Operating System by William Wulf, E. Cohen, W. Corwin, Anita Jones, R. Levin, C. Pierson and F. Pollack in Communications of the ACM, June, 1974.

---

This page last modified on 2011 October 9.