Introduction ============ Administrivia MW 2:30-4 in 36-155 experimental course: rough edges, provide feedback! lectures: will cover a range of topics in systems security each lecture will be based around a paper you should read beforehand we'll go through the paper and discuss the ideas in class -> feel free to interrupt, ask questions, point out mistakes papers/topics prone to change suggest topics you'd like to hear more about tests: one mid-term quiz, one quiz at the end of the semester (not during finals week though) overall plan: 3-4 labs, then final project lab 1 will be posted on Monday -- buffer overflows final project will span the second half of the course presentations on last day (or two days, depending on # of groups) as you're taking the course, think of projects you'd like to work on sign up for course email list pass around a signup sheet What is security? Security goals, threat models security: achieving some goal in the presence of an attacker usual setting: 1 goal/policy: we have a system, and we want it to work a certain way 2 attacker: there is an attacker that can try to subvert our system's goal 3 threat model: make assumptions about what the attacker can/cannot do 4 design: try to design system to uphold goal despite attacker's actions 1. policy vs mechanism: - usually have some policy in mind, but lots of policies are possible - focus on general-purpose mechanisms, build blocks that can be used to enforce different policies 2. negative goal: - often hard to enforce security, because it's a negative goal easy to give user access to file, hard to make sure there's no way other users can gain access to that file - weakest link matters 3. notion of a TCB: what are we assuming is not controlled by the attacker? terminology: trust: belief that something will not be compromised/fail often vague trustworthy: it's actually worth trusting (it won't be compromised/fail) good thing! trusted: your security depends on the security of that thing (for better or worse) bad thing! often transitive: if you trust google, and google trusts someone else, you might have no choice but to end up trusting that someone too 4. typical design goals: reduce the amount of trusted components increase the trustworthiness of components example threat models internet means attackers are everywhere so almost every system needs to address security Multi-user machine wants to enforce controlled sharing worried about users that might gain access to secret docs, or corrupt tools: OS access control checks worried that users might modify the kernel or tamper with hardware tools: hardware-assisted isolation between user processes and kernel memory processes have to communicate with kernel (and each other) via syscalls isolation is a very powerful technique for security Web site wants to ensure credit card data is not stolen on the network worried about network attackers, wireless sniffers, etc tools: crypto, secure protocols Web site wants to ensure attacker can't steal other users' data worried about bugs in application code tools: type-safe languages, program analysis, privilege separation, information flow control, .. Web site wants to prevent denial of service quite different kind of problem used to be network attacks, now CPU, database attacks tools: accountability, explicit resource allocation, .. hard problem to solve when you can't clearly distinguish good&bad guys DoS attacks on security mechanism (lock out after 3 bad login attempts) Desktop machine wants to prevent outside connections worried about worms/attackers breaking in over the network tools: firewall drops incoming connections Single-user desktop wants to access different web sites safely worried about client-side web application code getting too much access similar to previous setting, except we have untrusted code what's really going on: richer API for code than for HTTP req's before tools: type-safe languages, static checking, sandboxing, etc. Web site wants to ensure data is not misused on the client machine worried about users ripping music, videos? DRM tools: TPM hardware. more interesting: server can't leak password? lots of other examples, different techniques for different threat models security problems stem from misplaced assumptions/trust -- negative goal - attacker does something new (crypto: trick user into revealing key; find it somewhere) - code is correct -- you actually check ACLs, encrypt data, etc everywhere - layering hides details, makes it difficult to reason abou what attacker can do sort-of a variant of the above - crypto primitives are secure (often OK but changes over time!) - crypto primitives used correctly (often subtle problems, hard to find!) interesting examples of what goes wrong firewall what if someone connects to your wireless network? what if they trick some program on your computer into bypassing the firewall? e.g. disabling the firewall itself: redirect user's browser to http://192.168.1.1/disableFirewall hardware assumptions java VM escape via random bit-flips with heat lamp? tempest -- keyboard, display cache timing attacks cold boot attacks military OS security auditing: often compromised by injecting backdoors into code through poorly-secured development system (also insider attacks; e.g. someone submitted a buggy patch to Linux kernel, that one happened to be caught, but others?) file access control: only nickolai can read grades.txt maybe someone else can change the editor? maybe someone else can trick me into revealing grades.txt? maybe someone else can trick OS into thinking grades.txt is schedule.txt? SQL injection buffer overflows SSL: trick Verisign into issuing you a certificate for amazon.com this happened with microsoft a while ago just required an official-looking fax secure system design principles improve trustworthiness of your TCB reduce the size of the TCB (less trusted code) end-to-end security (goes hand-in-hand with reducing TCB) economy of mechanism narrower interface, fewer components => easier to achieve negative goal principle of least privilege make the defaults secure open design - makes it clear what the threat model and assumptions are. - hiding the design is often not practical, hard to reason about what security you get from a secret design. --- rest of lecture: access control typical model: principals, objects, reference monitor access matrix authentication (figure out the principal) user provides password crypto protocol proves the user knows the password user proves he has a device (smartcard) biometrics authorization (figure out if principal can access object) access control lists (stored with object) easy to figure out who has access tickets (stored with principal) easy to delegate privileges decouples authentication, access matrix, and authorization hard to revoke access chase down every user and get the ticket back invalidate all outstanding tickets access control in Unix [ unix protection largely a failure, but interesting to look at, and lots of other work builds on it or refers to it. ] goal: safely support multiple users on the same computer why is the OS in charge? hard to go lower: OS is providing the abstractions we're talking about processes, files, devices our presumption is that we can't go higher users run arbitrary applications, not to be trusted in general subjects/principals: 32-bit values each process is running as some principal (uid) root (uid 0) is superuser, can change uid to any value other uid's cannot do this so, usually there's a login program that runs as root checks username/password against a password file if username/password matches, sets uid to user's and runs shell weakness: what if the login program is buggy? not a great model for login: way too much privileged code rlogind runs "login [-f] username", -f if already authenticated user asks to log in as user "-froot", avoids password check, gets root neither rlogind nor login should have been running as root? how does unix implement authorization? objects: files, directories, processes, devices, .. operations: for files: read, write for directories: list, lookup, delete, create, rename, .. for processes: start, kill, debug, list, .. for devices: device-specific (rewind tape, clear screen, eject CD) hard to manage all these operations, so Unix maps most ops to read/write traditional unix: each object has an owner uid (file, dir, proc, ..) object permissions specified in terms of what owner can do, and others often there's also a group and rights for principals in that group some permissions are implicit no way to specify permissions on who can kill a process it's always "owner (same uid) can kill process" no way to specify who can change file permissions (only owner) aside: some unix objects have yet another authorization scheme fds: process that has an open FD can access it, like a capability getting the exit status of a process: must be a parent of that proc (as you can guess, protection in Unix is a mess, no underlying principle) what if you want to talk about other operations? special bits, like a sticky bit on directories for no-unlink some file systems have extended Unix permissions to be more flexible AFS ACLs: more operations (rlidwka) read list insert delete write lock change-acl what does unix get wrong from our design principles? POLP: root required for many things, hard to run with less priv almost every interesting daemon runs with full root privileges why? because originally Unix had everything interesting in the kernel namely, the file system was about the only thing worth protecting economy of mechanism: not really, many disparate security mechanisms all focused on time sharing a Unix machine between users, little else reduce size of TCB: maybe OK if your security policy is about Unix users not so great if your security policy is about something else we'll see next week how to build a secure application on top of Unix [ did not talk about in lecture: ] what do we do about operations that the kernel doesn't understand? rely on privileged programs but so far we can only reduce our privileges (start out as root, setuid to user) how to change privileges if we're already running as some uid? setuid programs couples privileges with some code trusted with those privileges e.g. "su" binary -- runs as root (uid 0) but requires password why might setuid binaries be a bad idea? attacker (caller) controls way too much of the environment env. variables ($LD_PRELOAD, $PATH, ..) name space (i.e. why chroot is not allowed for users) file descriptors (what if stdout is closed?) caller can send signals to terminate process better alternative? windows: can pass privileges from one process to another over IPC privileged daemon runs, accepts well-defined messages over IPC don't have to worry about quite so many untrusted inputs/variables