Understanding Least Privilege and Privilege Separation in Computer Security, Exams of Design

Download Understanding Least Privilege and Privilege Separation in Computer Security and more Exams Design in PDF only on Docsity! Deian Stefan Slides adopted from John Mitchell, Dan Boneh, and Stefan Savage CSE 127: Computer Security Least privilege and privilege separation This week… • How to build secure systems ➤ Least privilege and privilege separation ➤ Sandboxing and isolation • Key is underlying principles not mechanisms ➤ We’re going to look at systems techniques ➤ Other ways to achieve similar goals: language-based Principle of Least Privilege Defn: A system should only have the minimal 
 privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource Principle of Least Privilege Defn: A system should only have the minimal 
 privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource Principle of Least Privilege Defn: A system should only have the minimal 
 privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource How dow we break things apart? Map compartment to user ids! • Recall: permissions in UNIX granted according to UID ➤ A process may access files, network sockets, …. • Each process has UID • Each file has ACL ➤ Grants permissions to users according to UIDs and
 roles (owner, group, other) ➤ Everything is a file! How many UIDs does a process have? • A: one • B: two • C: three • D: four Process UIDs • Real user ID (RUID) ➤ same as the user ID of parent (unless changed) ➤ used to determine which user started the process • Effective user ID (EUID) ➤ from setuid bit on the file being executed, or syscall ➤ determines the permissions for process • Saved user ID (SUID) ➤ Used to save and restore EUID Process UIDs • Real user ID (RUID) ➤ same as the user ID of parent (unless changed) ➤ used to determine which user started the process • Effective user ID (EUID) ➤ from setuid bit on the file being executed, or syscall ➤ determines the permissions for process • Saved user ID (SUID) ➤ Used to save and restore EUID SetUID demystified (a bit) • Root ➤ ID=0 for superuser root; can access any file • fork and exec system calls ➤ Inherit three IDs, except exec of file with setuid bit • setuid system call ➤ seteuid(newid) can set EUID to ➤ Real ID or saved ID, regardless of current EUID ➤ Any ID, if EUID is root SetUID demystified (a bit) • There are actually 3 bits: ➤ setuid - set EUID of process to ID of file owner ➤ setgid - set EGID of process to GID of file ➤ sticky bit ➤ on: only file owner, directory owner, and root can 
 rename or remove file in the directory ➤ off: if user has write permission on directory, can
 rename or remove files, even if not owner SetUID demystified (a bit) • There are actually 3 bits: ➤ setuid - set EUID of process to ID of file owner ➤ setgid - set EGID of process to GID of file ➤ sticky bit ➤ on: only file owner, directory owner, and root can 
 rename or remove file in the directory ➤ off: if user has write permission on directory, can
 rename or remove files, even if not owner Where have you seen this? drwxrwxrwt 16 root root 700 Feb 6 17:38 /tmp/ -rwsr-xr-x 1 root root 55440 Jul 28 2018 /usr/bin/passwd Example 1: Mail agent • Requirements ➤ Receive and send email over external network ➤ Place incoming email into local user inbox files • Sendmail ➤ Monolithic design ➤ Historical source of many vulnerabilities • Qmail ➤ Compartmentalized design qmail design • Isolation based on OS isolation ➤ Separate modules run as separate “users” ➤ Each user only has access to specific resources • Least privilege ➤ Minimal privileges for each UID ➤ Only one “setuid” program ➤ Only one “root” program structure of qmail qmail-smtpd qmail-localqmail-remote qmail-lspawnqmail-rspawn qmail-send qmail-inject qmail-queue Incoming external mail Incoming internal mail qmail-smtpd qmail-localqmail-remote qmail-lspawnqmail-rspawn qmail-send qmail-inject qmail-queue qmaild user qmailq qmailsqmailr qmailr root user setuid user structure of qmail qmail-smtpd qmail-localqmail-remote qmail-lspawnqmail-rspawn qmail-send qmail-inject qmail-queue qmaild user qmailq qmailsqmailr qmailr root user setuid user Reads incoming mail directories Splits message into header, body Signals qmail-send structure of qmail qmail-smtpd qmail-localqmail-remote qmail-lspawnqmail-rspawn qmail-send qmail-inject qmail-queue qmaild user qmailq qmailsqmailr qmailr root user setuid user structure of qmail qmail-send signals • qmail-lspawn if local • qmail-remote if remote qmail-smtpd qmail-localqmail-remote qmail-lspawnqmail-rspawn qmail-send qmail-inject qmail-queue qmaild user qmailq qmailsqmailr qmailr root user setuid user structure of qmail qmail-remote • Delivers message to remote MTA Android design • Isolation: Each app runs with own UID (own VM) ➤ Provides memory protection ➤ Communication limited to using UNIX domain sockets + reference monitor checks permissions ➤ Only ping and zygote run as root • Least Privilege: Applications announces permission ➤ User grants access at install time + runtime okws design • Isolation: each service runs with own UID ➤ Each service run in a chroot jail, restricted to ➤ Communication limited to structured RPC between service and DB • Least privilege ➤ Each UID is unique non privileged user ➤ Only okld (launcher daemon) runs as root Browser security architecture • Browser is an execution environment ➤ Has access control policies similar to an OS • Browser runs under control of an OS ➤ Use least privilege to keep the browser code secure against attacks that would break the browser enforcement of web security policy What’s the security model? Operating system • Subject: Processes –Has User ID (UID, SID) –Discretionary access control • Objects – File –Network –… • Vulnerabilities –Untrusted programs –Buffer overflow –… Web browser • Subject: web content (JavaScript) –Has “Origin” –Mandatory access control • Objects –Document object model – Frames –Cookies / localStorage • Vulnerabilities –Cross-site scripting – Implementation bugs –… Chromium security architecture • Browser ("kernel") ➤ Full privileges (file system, networking) • Rendering engine ➤ Can have multiple processes ➤ Sandboxed • One process per plugin ➤ Full privileges of browser Are UIDs enough? • A: yes • B: no What else do we need? • We need to confine code running in renderer ➤ Restrict code from reading the filesystem, talking to network, etc. if compromised • On Linux this is done with seccomp-bpf ➤ seccomp - “secure computing mode”: no sys calls except exit, sigreturn, read, and write to already open FDs ➤ seccomp-bpf - syscall firewall filtering