Protection
Lecture Notes for CS 140
Spring 2019
John Ousterhout
- Readings for this topic from Operating Systems: Principles and Practice:
none.
- Protection: mechanisms that prevent accidental or intentional
misuse of a system.
- Intentional abuse much more difficult to eliminate than accidents.
- 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: control access using authentication and authorization
information.
A tiny flaw in any of these areas can compromise the entire
protection mechanism.
Authentication
- Historically 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.
- Must be cheap to make, hard to duplicate or forge.
- Two-factor authentication with cell phones:
- Factor #1: traditional password during login
- Factor #2: cell phone acts like a key:
- Site sends text to phone with one-time passcode
- User must read passcode from phone, type into login page
- To hijack your account, attacker must have both your password
and your cell phone
- Optimization for Web sites:
- Once two-factor authentication complete, load cookie into
your browser
- Cookie turns your browser into a form of key
- Login with password as long as cookie exists
- To login from a different browser/machine, must go through
two-factor authentication again
- Two-factor authentication great for Web sites:
- Can't attack without physical presence (steal your cell phone)
- Must also have your password
- After you log in, your user id is associated with every
process executed under that login:
- User id stored in process control block.
- Children inherit the user id from their parents.
- Once authentication is complete, the identity of the
principal must be protected from tampering, since other
parts of the system will rely on it.
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: very simple (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
- Windows provides a more general form of ACL
- 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 name, 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.
- Several projects in the 1970's and 1980's tried to use capabilities
exclusively for all protection (including files); but they were
awkward to use.
- Capability-like approaches have reappeared in recent years in
certain contexts.
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 maps.
- In most operating systems, the entire OS has unlimited power.
- Alternative approach: Security kernel
- An inner layer of the operating system that enforces security;
only this layer has total power.
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.