Lecture notes for Operating Systems

Lecture Notes for Operating Systems

Protection and Security, 9 December 2002

fundamentals
1. security is an adversarial game you play
  1. if the rules support the game, you win; if not, you lose
  2. what's the point of the game - it may not be what you think
  3. it's important to understand the game and the rules
2. objectives, policy, and mechanism - the why, the what, and the how
  1. objectives determine overall goals
    1. only those that need information can get it
    2. every resource use is traced back to a billable entity
    3. it is impossible to discern the agents responsible for an action
  2. policy determines what the rules are
    1. security classifications, RADIUS, anonymity
  3. mechanism determines how the rules are implemented
    1. disjoint systems, challenge-response, hot-potato routing
  4. the difference is the level of detail - one level's objectives is another level's policy, and so on
3. making policy match objectives, mechanism match policy
4. basic computer security policies
  1. authentication - every entity is an identified, known entity
  2. authorization - entities must have permission to carry out actions on objects
  3. quotas - user's rate of resource use must be constrained
  4. computers are anti-security devices
    1. computers are dumb, and require detailed, correct instructions to work
    2. software is infinitely malleable - hardware too, to a lesser extent
    3. everything looks the same on a computer
5. observations
  1. security is a process, not a mechanism
  2. there are many levels to security, the computer is perhaps the least important (but the most damaging)
  3. security is expensive
authentication - who are you
1. verifying and tagging a claim of identity
2. mechanisms - prove your claim
  1. mental - tell me a secret - password protection, ticketing schemes
  2. physical - characteristic traits; - biometrics
  3. internal and external authentication - external is more costly
3. attacks
  1. a masquerade is an attack on authentication - unfortunately, it's also a generally useful technique; unix set-uid bits
  2. identity theft - network packet sniffers
  3. trojan horses - login trojans
4. example - kerberos
  1. developed for project athena - a campus-wide open network of computers
  2. an authentication server - clients receive secrets they can share with each other
  3. the kerberos server must be trusted and secure
authorization - what can you do to what
1. important for resource control - sharing and security
2. authorization models
  1. agents, actions, objects (which may be agents) - actions are related to objects
  2. no authorization - any agent can do any operation on any object
  3. more restrictive policies are organized as a matrix
    1. agents by objects gives operations
    2. sometimes agents are replaced by protection domains - indirection
    3. matrix elements are determined by the policy
    4. the matrix itself is an object with actions
  4. the security monitor (or kernel) checks that an (agent, action, object) triple is given in the matrix
    1. must be protected and trusted - but frees up other software from being so
    2. required on every operation
3. implementation
  1. lock and key - tell me a secret; usually timestamped; kerberos's ticket-granting service
  2. access matrix - very expensive; the matrix is huge and sparse; the security monitor is expensive to invoke
  3. access control lists - slice the access matrix down the columns
    1. each object has a list of agents and the operations they can perform
    2. non-monolithic - each class of object can be checked separately
  4. capabilities - slice the access matrix across the rows
    1. each agent has a list of objects and operations it can perform
    2. flexible - capabilities can be passed around (with permission)
    3. expensive - a security monitor needs to check capabilities

This page last modified on 9 December 2002.