View access control as a matrix Protection Ali Mashtizadeh Stanford University Subjects (processes/users) access objects (e.g., files) • Each cell of matrix has allowed permissions • 1 / 39 2 / 39 Specifying policy Two ways to slice the matrix Manually filling out matrix would be tedious • Use tools such as groups or role-based access control: • Along columns: • - Kernel stores list of who can access object along with object - Most systems you’ve used probably do this dir 1 - Examples: Unix file permissions, Access Control Lists (ACLs) Along rows: • dir 2 - Capability systems do this - More on these later. dir 3 3 / 39 4 / 39 Outline Example: Unix protection Each process has a User ID & one or more group IDs • System stores with each file: • 1 Unix protection - User who owns the file and group file is in - Permissions for user, any one in file group, and other Shown by output of ls -l command: 2 Unix security holes • user group other owner group - rw- rw- r-- dm cs140 ... index.html 3 Capability-based protection - Eachz}|{ groupz}|{ z}|{ of threez}|{ lettersz }| { specifies a subset of read, write, and execute permissions - User permissions apply to processes with same user ID - Else, group permissions apply to processes in same group - Else, other permissions apply 5 / 39 6 / 39 Unix continued Non-file permissions in Unix Directories have permission bits, too • Many devices show up in file system • - Need write permission on a directory to create or delete a file - E.g., /dev/tty1 permissions just like for files Special user root (UID 0) has all privileges • Other access controls not represented in file system • - E.g., Read/write any file, change owners of files E.g., must usually be root to do the following: - Required for administration (backup, creating new users, etc.) • - Bind any TCP or UDP port number less than 1,024 Example: • - Change the current process’s user or group ID - drwxr-xr-x 56 root wheel 4096 Apr 4 10:08 /etc - Mount or unmount file systems - Directory writable only by root, readable by everyone - Create device nodes (such as /dev/tty1) in the file system - Means non-root users cannot directly delete files in /etc - Change the owner of a file - Execute permission means ability to use pathnames in the - Set the time-of-day clock; halt or reboot machine directory, separate fromread permission which allows listing 7 / 39 8 / 39 Example: Login runs as root Setuid Unix users typically stored in files in /etc Some legitimate actions require more privs than UID • • - Files passwd, group, and often shadow or master.passwd - E.g., how should users change their passwords? For each user, files contain: - Stored in root-owned /etc/passwd & /etc/shadow files • Textual username (e.g., “dm”, or “root”) Solution: Setuid/setgid programs - • - Numeric user ID, and group ID(s) - Run with privileges of file’s owner or group - One-way hash of user’s password: salt, H(salt, passwd) - Each process has real and effective UID/GID { } - Other information, such as user’s full name, login shell, etc. - real is user who launched setuid program /usr/bin/login runs as root - effective is owner/group of file, used in access checks • - Actual rules and interfaces somewhat complicated [Chen] - Reads username & password from terminal Looks up username in /etc/passwd, etc. Shown as “s” in file listings - • - Computes H(salt, typed password) & checks that it matches - -rws--x--x 1 root root 38464 Jan 26 14:26 /bin/passwd - If matches, sets group ID & user ID corresponding to username - Obviously need to own file to set the setuid bit - Execute user’s shell with execve system call - Need to own file and be in group to set setgid bit 9 / 39 10 / 39 Setuid (continued) Other permissions Examples • When can proc. A send a signal to proc. B w. kill? - passwd – changes user’s password • - su – acquire new user ID (given correct password) - Allow if sender and receiver have same effective UID - sudo – run one command as root - But need ability to kill processes you launch even if suid - ping – uses raw IP sockets to send/receive ICMP packets - So allow if real UIDs match, as well Have to be very careful when writing setuid code - Can also send SIGCONT w/o UID match if in same session • - Attackers can run setuid programs any time (no need to wait for Debugger system call ptrace • root to run a vulnerable job) - Lets one process modify another’s memory - Attacker controls many aspects of program’s environment - Setuid gives a program more privilege than invoking user Example attacks when running a setuid program • - So don’t let process ptrace more privileged process - Change PATH or IFS if setuid prog calls system(3) - E.g., Require sender to match real & effective UID of target - Set maximum file size to zero (if app rebuilds DB) - Also disable/ignore setuid if ptraced target calls exec - Close fd 2 before running program—may accidentally send error - Exception: root can ptrace anyone message into protected file 11 / 39 12 / 39 rename (“/tmp/badetc” “/tmp/x”) → symlink (“/etc”, “/tmp/badetc”) Time-of-check-to-time-of-use [TOCTTOU] bug • - find checks that /tmp/badetc is not symlink - But meaning of file name changes before it is used if (access (logfile, W_OK) < 0) return ERROR; xterm is root, but shouldn’t log to file user can’t write • access call avoids dangerous security hole • - Does permission check with real, not effective UID - Wrong: Another TOCTTOU bug - Wrong: Another TOCTTOU bug Outline A security hole Even without root or setuid, attackers can trick root • owned processes into doing things. 1 Unix protection Example: Want to clear unused files in /tmp • Every night, automatically run this command as root: • 2 Unix security holes find /tmp -atime +3 -exec rm -f -- {} \; find identifies files not accessed in 3 days • - executes rm, replacing with file name 3 Capability-based protection {} rm -f -- path deletes file path • - Note “--” prevents path from being parsed as option What’s wrong here? • 13 / 39 14 / 39 An attack An attack find/rm Attacker find/rm Attacker mkdir (“/tmp/badetc”) mkdir (“/tmp/badetc”) creat (“/tmp/badetc/passwd”) creat (“/tmp/badetc/passwd”) readdir (“/tmp”) “badetc” readdir (“/tmp”) “badetc” → → lstat (“/tmp/badetc”) DIRECTORY lstat (“/tmp/badetc”) DIRECTORY → → readdir (“/tmp/badetc”) “passwd” readdir (“/tmp/badetc”) “passwd” → → rename (“/tmp/badetc” “/tmp/x”) → symlink (“/etc”, “/tmp/badetc”) unlink (“/tmp/badetc/passwd”) unlink (“/tmp/badetc/passwd”) Time-of-check-to-time-of-use [TOCTTOU] bug • - find checks that /tmp/badetc is not symlink - But meaning of file name changes before it is used 15 / 39 15 / 39 xterm command xterm command Provides a terminal window in X-windows Provides a terminal window in X-windows • • Used to run with setuid root privileges Used to run with setuid root privileges • • - Requires kernel pseudo-terminal (pty) device - Requires kernel pseudo-terminal (pty) device - Required root privs to change ownership of pty to user - Required root privs to change ownership of pty to user - Also writes protected utmp/wtmp files to record users - Also writes protected utmp/wtmp files to record users Had feature to log terminal session to file Had feature to log terminal session to file • • if (access (logfile, W_OK) < 0) return ERROR; fd = open (logfile, O_CREAT|O_WRONLY|O_TRUNC, 0666); fd = open (logfile, O_CREAT|O_WRONLY|O_TRUNC, 0666); /* ...*/ /* ...*/ What’s wrong here? xterm is root, but shouldn’t log to file user can’t write • • access call avoids dangerous security hole • - Does permission check with real, not effective UID 16 / 39 16 / 39 xterm command An attack Provides a terminal window in X-windows • xterm Attacker Used to run with setuid root privileges • creat (“/tmp/X”) - Requires kernel pseudo-terminal (pty) device access (“/tmp/X”) OK → - Required root privs to change ownership of pty to user unlink (“/tmp/X”) symlink (“/tmp/X” “/etc/passwd”) - Also writes protected utmp/wtmp files to record users → open (“/tmp/X”) Had feature to log terminal session to file • Attacker changes /tmp/X between check and use if (access (logfile, W_OK) < 0) • return ERROR; - xterm unwittingly overwrites /etc/passwd fd = open (logfile, O_CREAT|O_WRONLY|O_TRUNC, 0666); - Another TOCTTOU bug /* ...*/ OpenBSD man page: “CAVEATS: access() is a potential • xterm is root, but shouldn’t log to file user can’t write security hole and should never be used.” • access call avoids dangerous security hole • - Does permission check with real, not effective UID - Wrong: Another TOCTTOU bug 16 / 39 17 / 39 Preventing TOCCTOU SSH configuration files SSH 1.2.12 client ran as root for several reasons: • - Needed to bind TCP port under 1,024 (privileged operation) Use new APIs that are relative to an opened directory fd • - Needed to read client private key (for host authentication) - openat, renameat, unlinkat, symlinkat, faccessat Also needed to read & write files owned by user - fchown, fchownat, fchmod, fchmodat, fstat, fstatat • - Some TOCCTOU problems can exist with hardlinks and symlinks - Read configuration file ~/.ssh/config - Record server keys in ~/.ssh/known hosts Lock resources but most systems only lock files • Software structured to avoid TOCTTOU bugs: Wrap groups of operations in OS transactions • • - First bind socket & read root-owned secret key file - Microsoft supports for transactions on Windows Vista and newer - Second drop all privileges—set real, & effective UIDs to user - CreateTransaction, CommitTransaction, RollbackTransaction - Only then access user files - A few research projects for POSIX [1] [2] - Idea: avoid using any user-controlled arguments/files