Protection

Optional 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.
  • 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 and AFS provide more general forms 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</i
  • 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.