Protection and Security

Lecture Notes for CS 140
Winter 2012
John Ousterhout

  • Readings for this topic from Operating System Concepts: Chapter 14, Sections 15.1-15.3, 15.5, 15.6.
  • 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.
    • Must not be stored in a directly-readable form: use one-way transformations.
    • Passwords should be relatively long and obscure.
  • Alternate form of authentication: badge or key.
    • Does not have to be kept secret.
    • Should not be forgable or copyable.
    • Can be stolen, but owner will know if it is.
  • 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.
  • Once 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.
    • Almost as if there were no root directory in Unix and no "..".
  • 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 very 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: sSecurity 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

  • There are many other things that need to be protected besides just file access
    • In Unix, root access is used to control most of these things.
  • Some common problems:
    • Account penetration (guess password)
    • Abuse of valid privileges.
    • Trojan Horse: modify valid program to misbehave or steal information.
    • Impersonation/phishing: create the appearance of a trusted application, trick users into divulging personal information
    • Network attack: snoop on network traffic or other communications and steal unprotected information (e.g. passwords).
    • Denial of service: create program that uses up all system resources to make system crash or prevent others from getting work done
    • Worm or virus: a Trojan Horse that can spread itself from machine to machine (exploiting bugs and loopholes)
  • Examples of successful attacks:
    • Tenex page-fault password attack
    • Botnets and denial of service
    • "Salami attack": checking account interest calculator that credited fractional cents to the account of the creator
  • It may not be possible to tell that a system has been penetrated. Example of undetectable Trojan Horse:
    • Modify login program to recognize special login and give root privilege without a password.
    • But, people might notice the login code.
    • So, modify the compiler to figure out when it's compiling the login code and insert the Trojan Horse automatically.
    • But, people might notice the compiler code.
    • Modify the compiler to insert the compiler Trojan Horse.
    • Compile the compiler.
    • Remove the Trojan Horse from the sources.
    • The Trojan Horse is completely hidden in the binaries!
  • Once penetrated, it may be difficult or impossible to secure it again: too many complex Trojan Horses.
  • Any bug can result in a security loophole, and all systems have bugs.

Security Solutions

  • Logging: record important actions and uses of privilege
  • Principle of minimum privilege: limit access to only what is absolutely needed.
  • Involve humans more:
    • Auditing code to catch bugs and Trojan Horses.
    • Human approval for particularly dangerous operations (e.g., large funds transfers)
  • Prove correctness of system (absence of bugs)