OKWS ==== Today's lecture: how to build a secure web server on Unix. The design of our lab web server, zookws, is inspired by OKWS. Background: security and protection in Unix Principals: user IDs, group IDs (32-bit integers) Each process has a user ID, and a list of group IDs What are the objects in Unix, and how does the OS do access control? Files, directories Each file has an owner user and group Each file has read, write, and execute perms for user, group, others Typically represented as a bit vector written base 8 (octal) Octal works well because each digit is 3 bits (read, write, exec) Who can change permissions on files? Only user owner (process UID). Execute for directory means being able to lookup names (but not ls) Checks for process opening file /etc/passwd: Must be able to look up 'etc' in /, 'passwd' in /etc Must be able to open /etc/passwd (read or read-write) Suppose you want file readable to intersection of group1 and group2. Is it possible to implement this in Unix? File descriptors File access control checks performed at file open Once process has an open file descriptor, can continue accessing Processes can pass file descriptors (via Unix domain sockets) Processes What can you do to a process? debug (ptrace), send signal, wait for exit & get status, .. Debugging, sending signals: must have same UID (almost) Various exceptions, this gets tricky in practice. Waiting / getting exit status: must be parent of that process Networking Almost no interaction with process UIDs/GIDs Firewall imposes its own checks, unrelated to processes One rule: only root (UID 0) can listen on ports below 1024 Switching UIDs/GIDs System calls: setuid(), setgid(), setgroups() Only root (UID 0) can call these system calls (to first approximation) Where does the user ID, group ID list come from? On a typical Unix system, login program runs as root (UID 0) Finds user's UID based on /etc/passwd Finds user's groups based on /etc/group Calls setuid(), setgid(), setgroups() before running user's shell How do you regain privileges after switching to a non-root user? Could use file descriptor passing (but have to write specialized code) Kernel mechanism: setuid/setgid binaries. When the binary is executed, set process UID or GID to binary owner Specified with a special bit in the file's permissions For example, su / sudo binaries are typically setuid root Even if your shell is not root, can run "su otheruser" su process will check passwd, run shell as otheruser if OK Many such programs on Unix, since root privileges often needed Why might setuid-binaries be a bad idea, security-wise? Many ways for adversary (caller of binary) to manipulate process In Unix, exec'ed process inherits environment, file descriptors, .. Libraries that a setuid program might use not sufficiently paranoid Historically, many vulnerabilities (e.g. pass $LD_PRELOAD, ..) How to prevent a malicious program from exploiting setuid-root binaries? Kernel mechanism: chroot Changes what '/' means when opening files by path name. Cannot name files (e.g. setuid binaries) outside chroot tree. For example, OKWS uses chroot to restrict programs to /var/okws/run, .. Kernel also ensures that '/../' does not allow escape from chroot. Why chroot only allowed for root? setuid binaries (like su) can get confused about what's /etc/passwd recursive calls to chroot() can allow escape from chroot jail Why hasn't chroot been fixed to confine a root process in that dir? Root can write kern mem, load kern modules, access disk sectors, .. Background: traditional web server architecture (Apache) Apache runs N identical processes, handling HTTP requests All processes run as user 'www' Application code (e.g. PHP) typically runs inside each of N apache processes Any accesses to OS state (files, processes, ...) performed by www's UID Storage: SQL database, typically one connection with full access to DB Problem: if any component is compromised, adversary gets all the data What kind of attacks might occur in a web application? Unintended data disclosure (getting page source code, hidden files, ..) Remote code execution (e.g., buffer overflow in Apache) Buggy application code (hard to write secure PHP code), e.g. SQL inj. Attacks on web browsers (cross-site scripting attacks) Back to OKWS: what's their application / motivation? Dating web site: worried about data secrecy Not so worried about adversary breaking in and sending spam Lots of server-side code execution: matching, profile updates, ... Must have sharing between users (e.g. matching) -- cannot just partition Good summary of overall plan: "aspects most vulnerable to attack are least useful to attackers" Why is this hard? Unix makes it tricky to reduce privileges (chroot, UIDs, ..) Applications need to share state in complicated ways Unix and SQL databases don't have fine-grained sharing control mechanisms How does OKWS partition the web server? Figure 1 in paper. How does a request flow in this web server? okd -> oklogd -> svc -> dbproxy -> pubd -> oklogd How does this design map onto physical machines? Probably many front-end machines (okld, okd, pubd, oklogd, svc) Several DB machines (dbproxy, DB) How does OKWS enforce isolation between components in Figure 1? Each service runs as a separate UID and GID. chroot used to confine each process to a separate directory (almost). Components communicate via pipes (or rather, Unix domain socket pairs). File descriptor passing used to pass around HTTP connections. What's the point of okld? Why isn't okld the same as okd? Why does okld need to run as root? (Port 80, chroot/setuid.) What does it take for okld to launch a service? Create socket pairs Get new socket to oklogd fork, setuid/setgid, exec the service Pass control sockets to okd What's the point of oklogd? What's the point of pubd? Why do we need a database proxy? Ensure that each service cannot fetch other data, if it is compromised. Where does the 20-byte token come from? Passed as arguments to service. Who checks the token? DB proxy has list of tokens (& allowed queries?) Who generates? Not clear; manual by system administrator? What if token disclosed? Compromised component could issue queries. Table 1: why are all services and okld in the same chroot? Is it a problem? How would we decide? What are the readable, writable files there? Readable: shared libraries containing service code. Writable: each service can write to its own /cores/. Where's the config file? /etc/okws_config, kept in memory by okld. Why does OKWS need a separate GID for every service? Need to execute binary, but file ownership allows chmod. Solution: binaries owned by root, service is group owner, mode 0410. Why 0410 (user read, group execute), and not 0510 (user read & exec)? Why not process per user? Is per user strictly better? user X service? Does OKWS achieve its goal? What attacks from the list of typical web attacks does OKWS solve, and how? Most things other than XSS are addressed. XSS sort-of addressed through using specialized template routines. What's the effect of each component being compromised, and "attack surface"? okld: root access to web server machine, but maybe not to DB. attack surface: small (no user input other than svc exit). okd: intercept/modify all user HTTP reqs/responses, steal passwords. attack surface: parsing the first line of HTTP request pubd: corrupt templates, leverage to maybe exploit bug in some service? attack surface: requests to fetch templates from okd, svcs. oklogd: corrupt/ignore/remove/falsify log entries attack surface: log messages from okd, okld, svcs service: send garbage to user, access data for svc (modulo dbproxy) attack surface: HTTP requests from users (+ control msgs from okd) dbproxy: access/change all user data in the database it's talking to attack surface: requests from authorized services requests from unauthorized services (easy to drop) How does OKWS compare to Apache? Overall, better design. okld runs as root, vs. nothing in Apache, but probably minor. Neither has a great solution to client-side vulnerabilities (XSS, ..) How might an adversary try to compromise a system like OKWS? Exploit buffer overflows or other vulnerabilities in C++ code Find a SQL injection attack in some dbproxy Find logic bugs in service code Find cross-site scripting vulnerabilities References: http://pdos.csail.mit.edu/6.858/2010/readings/setuid.pdf