Building Secure High-Performance Web Services with OKWS
Max Krohn
USENIX 2004

why are we reading this paper?
  an example of real-world secure system design
  illustrates principle of least privilege

overall web site picture
  apache, cgi-scripts, MySQL, file system
  cgi for: login, mail, chat, user profile, photos

problems with conventional web site s/w
  (Section 2)
  buffer overflow in cgi script, read/write others' passwords
    directly affects any component that talks to clients
  funny sql: select name from users where id = '%s'
    can't trust programmer to check for ' in the id string...
    and what if the s/w generating sql has been penetrated?  
  worst part: security only at edges: any penetration is full penetration

can we summarize the problems?
  1. service programmers write buggy code
  2. buggy code can read/write anything

what's OKWS's overall plan?
  1. isolate services
  2. minimize privs required by each isolated service
  3. minimize privs granted to each isolated service
  4. re-factor services to help w/ #1, and to reduce direct exposure

what are privileges?
  UNIX doesn't have a coherent useful abstraction
  if we have isolated compartments,
    privilege == ability to inspect/affect something outside our compartment
  e.g. read a file, start or kill a process, send an RPC

why is minimizing *required* privs hard?
  naively-written service may actually combine lots of functions
  e.g. chat-room code knows about passwords for authentication

why is minimizing *granted* privs hard?
  UNIX and SQL APIs aren't helpful
  UNIX exposes all files/directories by default
    so service can read (perhaps write) all kinds of files
  UNIX allows other kinds of weird interaction
    kill, ptrace
    create network connections
  SQL enforces a user-vs-table access rule
    but maybe we want to limit to certain rows, columns, or combinations

what's the unit of isolation in OKWS?
  the process

what's in each service process?
  why not combine e-mail with chat-room?
  should service make authentication decisions?
  should service directly read/write data files, e.g. password or e-mail-box?
  should one process serve different users?

interesting observation in intro:
  the most vulnerable modules are the least useful to attackers
  so, if it communicates w/ outside world, should not be able
    to directly *do* much of anything. i.e. little priv.
  and if process does something sensitive, no direct access
  layered defenses: front end, SQL proxy, SQL server

how does OKWS minimize a service's required privs?
  minimal per-service functionality
  don't put login authentication and chat-room in same service

how does OKWS minimize privs granted to each service?
  separate address space for each service
  chroot/jail
  unique UIDs
  SQL RPC proxies, simple authentication
  pubd and oklogd

okws processes (Figure 1)
  okld: launch various processes
  okd: dispatch incoming HTTP GETs
  pubd: read-only config and template files
  oklogd

what will attacker see under OKWS?
  *can* break into some services due to bugs
  can't read/write any files
  can send RPCs to sql proxy, logger, pubd

remaining flaws?
  if okws were penetrated, how would we expect it to happen?
  C++ still too low-level (C strings, C arrays, &c)
  single service serves many users