Outline OS security: protection and isolation CSci 5271 OS - PDF document

Outline OS security: protection and isolation CSci 5271 OS security: authentication Introduction to Computer Security Announcements intermission Day 9: OS security basics Stephen McCamant Basics of access control University of Minnesota, Computer Science & Engineering Unix-style access control OS security topics Protection and isolation Resource protection: prevent processes from accessing hardware Resource protection Process isolation: prevent processes Process isolation from interfering with each other User authentication Design: by default processes can do Access control neither Must request access from operating system Reference monitor Hardware basis: memory protection Complete mediation: all accesses are Historic: segments checked Modern: paging and page protection Tamperproof: the monitor is itself Memory divided into pages (e.g. 4k) Every process has own virtual to physical protected from modification page table Small enough to be thoroughly verified Pages also have R/W/X permissions

Linux 32-bit example Hardware basis: supervisor bit Supervisor (kernel) mode: all instructions available User mode: no hardware or VM control instructions Only way to switch to kernel mode is specified entry point Also generalizes to multiple “rings” Outline Authentication factors OS security: protection and isolation Something you know (password, PIN) OS security: authentication Something you have (e.g., smart card) Something you are (biometrics) Announcements intermission CAPTCHAs, time and location, . . . Basics of access control Multi-factor authentication Unix-style access control Passwords: love to hate Password entropy Model password choice as probabilistic Many problems for users, sysadmins, process researchers If uniform, log ✷ ❥ ❙ ❥ But familiar and near-zero cost of entry Controls difficulty of guessing attacks User-chosen passwords proliferate for Hard to estimate for user-chosen low-stakes web site authentication passwords Length is an imperfect proxy

Password hashing Dictionary attacks Online: send guesses to server Idea: don’t store password or Offline: attacker can check guesses equivalent information internally Password ‘encryption’ is a Specialized password lists more long-standing misnomer effective than literal dictionaries E.g., Unix ❝r②♣t✭✸✮ Also generation algorithms (s ✦ $, etc.) Presumably hard-to-invert function ❤ ✘ 25% of passwords consistently Store only ❤ ✭ ♣ ✮ vulnerable Better password hashing Password usability User compliance can be a major Generate random salt s , store challenge ✭ s❀ ❤ ✭ s❀ ♣ ✮✮ Often caused by unrealistic demands Block pre-computed tables and equality inferences Distributed random passwords usually Salt must also have enough entropy unrealistic Deliberately expensive hash function Password aging: not too frequently AKA password-based key derivation Never have a fixed default password in function (PBKDF) Requirement for time and/or space a product Backup authentication Centralized authentication Desire: unassisted recovery from forgotten password Enterprise-wide (e.g., UMN ID) Fall back to other presumed-authentic Anderson: Microsoft Passport channel Today: Facebook Connect, Google ID Email, cell phone May or may not be single-sign-on Harder to forget (but less secret) shared information (SSO) Mother’s maiden name, first pet’s name Brittle: ask Sarah Palin or Mat Honan

Biometric authentication Example biometrics Authenticate by a physical body (Handwritten) signatures attribute Fingerprints, hand geometry ✰ Hard to lose Face and voice recognition ✲ Hard to reset Iris codes ✲ Inherently statistical ✲ Variation among people Error rates: ROC curve Outline OS security: protection and isolation OS security: authentication Announcements intermission Basics of access control Unix-style access control Note to early readers Outline OS security: protection and isolation This is the section of the slides most OS security: authentication likely to change in the final version Announcements intermission If class has already happened, make sure you have the latest slides for Basics of access control announcements Unix-style access control

Mechanism and policy Access control matrix Decision-making aspect of OS grades.txt /dev/hda /usr/bin/bcvi Should subject ❙ (user or process) be Alice r rw rx allowed to access object (e.g., file) ❖ ? Bob rw - rx Carol r - rx Complex, since admin must specify what should happen Slicing the matrix Groups/roles ❖ ✭ ♥♠ ✮ matrix impractical to store, Simplify by factoring out commonality much less administer Before: users have permissions Columns: access control list (ACL) After: users have roles, roles have Convenient to store with object permissions E.g., Unix file permissions Simple example: Unix groups Rows: capabilities Complex versions called role-based Convenient to store by subject E.g., Unix file descriptors access control (RBAC) Outline UIDs and GIDs OS security: protection and isolation To kernel, users and groups are just numeric identifiers OS security: authentication Names are a user-space nicety Announcements intermission E.g., ✴❡t❝✴♣❛ss✇❞ mapping Historically 16-bit, now 32 Basics of access control User 0 is the special superuser r♦♦t Unix-style access control Exempt from all access control checks

File mode bits Interpretation of mode bits File also has one user and group ID Core permissions are 9 bits, three Choose one set of bits groups of three If users match, use user bits Read, write, execute for user, group, If subject is in the group, use group bits other Otherwise, use other bits ❧s format: r✇① r✲① r✲✲ Note no fallback, so can stop yourself or have negative groups Octal format: 0754 But usually, ❖ ✒ ● ✒ ❯ Directory mode bits Process UIDs and s❡t✉✐❞✭✷✮ Same bits, slightly different UID is inherited by child processes, and interpretation an unprivileged process can’t change it Read: list contents (e.g., ❧s ) But there are syscalls root can use to Write: add or delete files change the UID, starting with s❡t✉✐❞ Execute: traverse E.g., login program, SSH server X but not R means: have to know the names Setuid programs, different UIDs More different UIDs Two mechanisms for temporary If 04000 “setuid” bit set, newly exec’d switching: process will take UID of its file owner Swap real UID and effective UID (BSD) Remember saved UID , allow switching to Other side conditions, like process not it (System V) traced Specifically the effective UID is changed, Modern systems support both while the real UID is unchanged mechanisms at the same time Shows who called you, allows switching Linux only: file-system UID back Once used for NFS servers, now mostly obsolete

Setgid, games Special case: ✴t♠♣ We’d like to allow anyone to make files Setgid bit 02000 mostly analogous to in ✴t♠♣ setuid So, everyone should have write But note no supergroup, so UID 0 is still permission special But don’t want Alice deleting Bob’s files Classic application: setgid ❣❛♠❡s for managing high-score files Solution: “sticky bit” 01000 Special case: group inheritance Other permission rules When using group to manage Only file owner or root can change permissions, want a whole tree to have permissions a single group Only root can change file owner When 02000 bit set, newly created Former System V behavior: “give away entries with have the parent’s group ❝❤♦✇♥ ” (Historic BSD behavior) Setuid/gid bits cleared on ❝❤♦✇♥ Also, directories will themselves inherit Set owner first, then enable setuid 02000 Non-checks “POSIX” ACLs Based on a withdrawn standardization File permissions on st❛t More flexible permissions, still fairly File permissions on link, unlink, rename Unix-like File permissions on read, write Multiple user and group entries Parent directory permissions generally Decision still based on one entry Except traversal Default ACLs: generalize group I.e., permissions not automatically inheritance recursive Command line: ❣❡t❢❛❝❧ , s❡t❢❛❝❧

ACL legacy interactions “POSIX” “capabilities” Hard problem: don’t break security of Divide root privilege into smaller ( ✘ 35) legacy code pieces Suggests: “fail closed” Note: not real capabilities Contrary pressure: don’t want to break functionality First runtime only, then added to FS Suggests: “fail open” similar to setuid POSIX ACL design: old group Motivating example: ♣✐♥❣ permission bits are a mask on all novel Also allows permanent disabling permissions Privilege escalation dangers Legacy interaction dangers Many pieces of the root privilege are Former bug: take away capability to enough to regain the whole thing drop privileges Access to files as UID 0 ❈❆P ❉❆❈ ❖❱❊❘❘■❉❊ Use of temporary files by no-longer ❈❆P ❋❖❲◆❊❘ setuid programs ❈❆P ❙❨❙ ▼❖❉❯▲❊ For more details: “Exploiting ❈❆P ▼❑◆❖❉ ❈❆P P❚❘❆❈❊ capabilities”, Emeric Nasi ❈❆P ❙❨❙ ❆❉▼■◆ ( ♠♦✉♥t ) Next time Object capability systems Mandatory access control Information-flow security