Security
-------------------
I. 2 Intro Examples
II. Security Overview
III. Server Security: Offense + Defense
IV. Unix Security + POLP
V. Example: OKWS
VI. How to Build a Website

I. Intro Examples
--------------------
1. Apache + OpenSSL 0.9.6a (CAN 2002-0656)
  - SSL = More security!

  unsigned int j;
  p=(unsigned char *)s->init_buf->data;
  j= *(p++);
  s->session->session_id_length=j;
  memcpy(s->session->session_id,p,j);

 - the result: an Apache worm

2. SparkNotes.com 2000:
 - New profile feature that displays "public" information about users
   but bug that made e-mail addresses "public" by default.
 - New program for getting that data:
 
     http://www.sparknotes.com/getprofile.cgi?id=1343

II. Security Overview
----------------------

What Is Security?
 - Protecting your system from attack.

 What's an attack?
 - Stealing data
 - Corrupting data
 - Controlling resources
 - DOS

 Why attack?
 - Money
 - Blackmail / extortion
 - Vendetta
 - intellectual curiosity
 - fame

Security is a Big topic

 - Server security -- today's focus.  There's some machine sitting on the
   Internet somewhere, with a certain interface exposed, and attackers
   want to circumvent it.
    - Why should you trust your software?

 - Client security
    - Clients are usually servers, so they have many of the same issues.
    - Slight simplification: people across the network cannot typically
      initiate connections.
    - Has a "fallible operator":
        - Spyware
        - Drive-by-Downloads

 - Client security turns out to be much harder -- GUI considerations,
   look inside the browser and the applications.
 - Systems community can more easily handle server security.
 - We think mainly of servers.

III. Server Security: Offense and Defense
-----------------------------------------
 - Show picture of a Web site.

 Attacks			|	Defense
----------------------------------------------------------------------------
 1. Break into DB from net	| 1. FW it off
 2. Break into WS on telnet	| 2. FW it off
 3. Buffer overrun in Apache	| 3. Patch apache / use better lang?
 4. Buffer overrun in our code  | 4. Use better lang / isolate it
 5. SQL injection		| 5. Better escaping / don't interpret code.
 6. Data scraping.              | 6. Use a sparse UID space.
 7. PW sniffing			| 7.  ???
 8. Fetch /etc/passwd and crack | 8. Don't expose /etc/passwd
     PW				|
 9. Root escalation from apache | 9. No setuid programs available to Apache
10. XSS                         |10. Filter JS and input HTML code.
11. Keystroke recorded on sys-  |11. Client security
    admin's desktop (planetlab) |
12. DDOS                        |12.  ???

Summary:
 - That we want private data to be available to right people makes
   this problem hard in the first place. Internet servers are there
   for a reason.
 - Security != "just encrypt your data;" this in fact can sometimes
   make the problem worse.
 - Best to prevent break-ins from happening in the first place.
 - If they do happen, want to limit their damage (POLP).
 - Security policies are difficult to express / package up neatly.

IV. Design According to POLP (in Unix)
---------------------------------------
 - Assume any piece of a system can be compromised, by either bad
   programming or malicious attack.
 - Try to limit the damage done by such a compromise (along the lines
   of the 4 attack goals).

 <Draw a picture of a server process on Unix, w/ other processes>

What's the goal on Unix?
 - Keep processes from communicating that don't have to:
    - limit FS, IPC, signals, ptrace
 - Strip away unneeded privilege 
    - with respect to network, FS.
 - Strip away FS access.

How on Unix?
 - setuid/setgid
 - system call interposition
 - chroot (away from setuid executables, /etc/passwd, /etc/ssh/..)

 <show Code snippet>

How do you write chroot'ed programs?
 - What about shared libraries?
 - /etc/resolv.conf?
 - Can chroot'ed programs access the FS at all? What if they need
   to write to the FS or read from the FS?
 - Fd's are *capabilities*; can pass them to chroot'ed services,
   thereby opening new files on its behalf.
 - Unforgeable - can only get them from the kernel via open/socket, etc.

Unix Shortcomings (round 1)
 - It's bad to run as root!
 - Yet, need root for:
    - chroot
    - setuid/setgid to a lower-privileged user
    - create a new user ID
 - Still no guarantee that we've cut off all channels
    - 200 syscalls!
    - Default is to give most/all privileges.
 - Can "break out" of chroot jails?
 - Can still exploit race conditions in the kernel to escalate privileges.

Sidebar
 - setuid / setuid misunderstanding
 - root / root misunderstanding
 - effective vs. real vs. saved set-user-ID

V. OKWS
-------
- Taking these principles as far as possible.
- C.f. Figure 1 From the paper..
- Discussion of which privileges are in which processes

<Table of how to hack, what you get, etc...>

- Technical details: how to launch a new service
- Within the launcher (running as root):

<on board:>

    // receive FDs from logger, pubd, demux
    fork ();
    chroot ("/var/okws/run");
    chdir ("/coredumps/51001");
    setgid (51001);
    setuid (51001);
    exec ("login", fds ... );

- Note no chroot -- why not?
- Once launched, how does a service get new connections?
- Note the goal - minimum tampering with each other in the 
  case of a compromise.

Shortcoming of Unix (2)
- A lot of plumbing involved with this system.  FDs flying everywhere.
- Isolation still not fine enough.  If a service gets taken over,
  can compromise all users of that service.

VI. Reflections on Building Websites
---------------------------------
- OKWS interesting "experiment"
- Need for speed; also, good gzip support.
- If you need compiled code, it's a good way to go.
- RPC-like system a must for backend communication
- Connection-pooling for free

Biggest difficulties:
- Finding good C++ programmers.
- Compile times.
- The DB is still always the problem.

Hard to Find good Alternatives
- Python / Perl - you might spend a lot of time writing C code / 
  integrating with lower level languages.
- Have to worry about DB pooling.
- Java -- must viable, and is getting better.  Scary you can't peer
  inside.
- .Net / C#-based system might be the way to go.


=======================================================================

Extra Material:

Capabilities (From the Eros Paper in SOSP 1999)

 - "Unforgeable pair made up of an object ID and a set of authorized 
   operations (an interface) on that object."
   - c.f. Dennis and van Horn. "Programming semantics for multiprogrammed
     computations," Communications of the ACM 9(3):143-154, Mar 1966.
 - Thus:
      <object ID, set of authorized OPs on that object>
 - Examples:
      "Process X can write to file at inode Y"
      "Process P can read from file at inode Z"
 - Familiar example: Unix file descriptors
 
 - Why are they secure?
    - Capabilities are "unforgeable"
    - Processes can get them only through authorized interfaces
    - Capabilities are only given to processes authorized to hold them

 - How do you get them?
    - From the kernel (e.g., open)
    - From other applications (e.g., FD passing)

 - How do you use them?
    - read (fd), write(fd).

 - How do you revoke them once granted?
   - In Unix, you do not.
   - In some systems, a central authority ("reference monitor") can revoke.
 
 - How do you store them persistently?
    - Can have circular dependencies (unlike an FS).
    - What happens when the system starts up? 
    - Revert to checkpointed state.
    - Often capability systems chose a single-level store.
 
 - Capability systems, a historical prospective:
    - KeyKOS, Eros, Cyotos (UP research)
        - Never saw any applications
    - IBM Systems (System 38, later AS/400, later 'i Series')
        - Commercially viable
 - Problems:
    - All bets are off when a capability is sent to the wrong place.
    - Firewall analogy?