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.