Backtracking Intrusions
King and Chen
SOSP 2003

why are we reading this paper?

what problem are they trying to solve?
  prevent people from breaking in?
  detect when someone has broken in?
  repair damage after a break-in?

what would constitute a failure of their backtracking system?
  someone is known to have broken in,
  but sys admin cannot figure out the original exploit.

what are some examples of exploits that the backtracking system might find?
  presumably servers with holes
  e.g. openssl-too
  maybe internal ones like ptrace or sendmail bug

why are the graphs like Figure 1 complex?
  why isn't the game up when the attacker gets the first sh/bash?

why is it hard to discover the original exploit?

does their system actually pinpoint the original exploit?

what do they do?
  log all dependency-causing events
  create a graph
  prune graph for relevance

what do their dependencies represent?
  when should the O/S declare a dependency?
  e.g. why do they treat reading attributes as a dependency?

what events do they prune?
  why was it OK to ignore events 2 and 7 in Figure 3?

what's the hard part?
  knowing what actions are useful to log?
  storing the huge log?
  protecting their log from the attacker?
  generating the dependency tree?
  pruning the tree?

they don't currently find dependencies via file names
  creating file, then list directory, is "low control"
  how could one take advantage of that?