diff options
| author | Austin Clements <amdragon@mit.edu> | 2011-09-07 11:49:14 -0400 |
|---|---|---|
| committer | Austin Clements <amdragon@mit.edu> | 2011-09-07 11:49:14 -0400 |
| commit | 01a6c054d548d9fff8bbdfac4d3f3de4ae8677a1 (patch) | |
| tree | 4320eb3d09f31f4a628b80d45482a72ee7c3956b /web/l-okws.txt | |
| parent | 64a03bd7aa5c03a626a2da4730a45fcceea75322 (diff) | |
| download | xv6-labs-01a6c054d548d9fff8bbdfac4d3f3de4ae8677a1.tar.gz xv6-labs-01a6c054d548d9fff8bbdfac4d3f3de4ae8677a1.tar.bz2 xv6-labs-01a6c054d548d9fff8bbdfac4d3f3de4ae8677a1.zip | |
Remove web directory; all cruft or moved to 6.828 repo
Diffstat (limited to 'web/l-okws.txt')
| -rw-r--r-- | web/l-okws.txt | 249 |
1 files changed, 0 insertions, 249 deletions
diff --git a/web/l-okws.txt b/web/l-okws.txt deleted file mode 100644 index fa940d0..0000000 --- a/web/l-okws.txt +++ /dev/null @@ -1,249 +0,0 @@ - -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? |