Protection
Lecture Notes for CS 140
Spring 2014
John Ousterhout
- Readings for this topic from Operating Systems: Principles and Practice:
none.
- Protection: mechanisms that prevent accidental or intentional
misuse of a system.
- Accidents: generally easier to solve (make them unlikely)
- Malicious abuse: much more difficult to eliminate (can't
leave any loopholes, can't use probabilities).
- Three aspects to a protection mechanism:
- Authentication: identify a responsible party (principal)
behind each action.
- Authorization: determine which principals are allowed to
perform which actions.
- Access enforcement: combine authentication and authorization
to control access.
A tiny flaw in any of these areas can compromise the entire
protection mechanism.
Authentication
- Typically done with passwords:
- A secret piece of information used to establish
identity of a user.
- Passwords should be relatively long and obscure (only useful
if hard to guess).
- The password database is a vulnerability and must be carefully
protected; for example, don't store passwords in a directly-readable
form (use one-way transformations).
- Alternate form of authentication: badge or key.
- Does not have to be kept secret.
- Can be stolen, but owner will know if it is.
- Should not be forgable or copyable.
- Paradox: key must be cheap to make, hard to duplicate.
- Once authentication is complete, the identity of the
principal must be protected from tampering, since other
parts of the system will rely on it.
- After you log in, your user id is associated with every
process executed under that login: each process inherits
the user id from its parent.
Authorization
- Goal: determine which principals can perform which
operations on which objects.
- Logically, authorization information represented as an
access matrix:
- One row per principal.
- One column per object.
- Each entry indicates what that principle can do to
that object.
- In practice a full access matrix would be too bulky, so
it gets stored in one of two compressed ways:
access control lists or capabilities.
- Access Control Lists (ACLs): organize by columns.
- With each object, store information
about which users are allowed to perform which operations.
- Most general form: list of <user, privilege> pairs.
- For simplicity, users can be organized into groups, with
a single ACL entry for an entire group.
- ACLs can be very general (Windows) or simplified (Unix).
- UNIX: 9 bits per file:
- owner, group, anyone
- read, write, execute permissions for each of the above
- In addition, user "root" has all permissions for
everything
- ACLs are simple and are used in almost all file systems.
- Capabilities: organize by rows.
- With each user, indicate which objects may be accessed,
and in what ways.
- Store a list of <object, privilege> pairs with each user.
This is called a capability list.
- Typically, capabilities also act as names for objects:
can't even name objects not referred to in your capability
list.
- Systems based on ACLs encourage visibility of objects:
shared public namespace.
- Capability systems discourage visibility; namespaces are
private by default.
- Capabilities have been used in experimental systems attempting
to be secure. However, they have proven to be clumsy to
use (painful to share things), so they have mostly fallen out
of favor for managing objects such as files.
Access Enforcement
- Some part of the system must be responsible for enforcing
access controls and protecting authentication and authorization
info.
- This portion of the system has total power, so it should be as
small and simple as possible. Example: the portion of the system
that sets up page tables.
- One possible approach: Security kernel
- An inner layer of the operating system that enforces security;
only this layer has total power.
- Most operating systems have no security kernel: the entire
OS has unlimited power.
Miscellaneous Issues
- Rights amplification
- A mechanism that causes a callee to acquire more privileges
(or different privileges) than its caller.
- Simple example: kernel call
- Another example: Unix set user id (setuid):
- Each file has one extra protection bit "s" (for setuid).
- Normally, each process runs with the same user id as the
process that created it.
- If an executable is invoked with setuid set, the effective
user id for that process changes to the owner of the
executable file.
- Typical use: setuid to root to perform protected operations
in a safe and controlled fashion.
- It is extremely difficult to make all of these mechanisms work with
no loopholes that can be exploited by evil-doers. Take CS 155 to
learn more.