Preview question In the Unix access control model, subjects are - PDF document

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

Hardware basis: supervisor bit Outline OS security: protection and isolation Supervisor (kernel) mode: all instructions available OS security: authentication User mode: no hardware or VM control instructions Announcements intermission Only way to switch to kernel mode is specified entry point Basics of access control Also generalizes to multiple “rings” Unix-style access control Authentication factors Passwords: love to hate Something you know (password, PIN) Many problems for users, sysadmins, researchers Something you have (e.g., smart card) But familiar and near-zero cost of entry Something you are (biometrics) User-chosen passwords proliferate for low-stakes CAPTCHAs, time and location, . . . web site authentication Multi-factor authentication Password entropy Password hashing Idea: don’t store password or equivalent information Model password choice as probabilistic process If uniform, log ✷ ❥ ❙ ❥ Password ‘encryption’ is a long-standing misnomer E.g., Unix ❝r②♣t✭✸✮ Controls difficulty of guessing attacks Presumably hard-to-invert function ❤ Hard to estimate for user-chosen passwords Store only ❤ ✭ ♣ ✮ Length is an imperfect proxy Dictionary attacks Better password hashing Online: send guesses to server Generate random salt s , store ✭ s❀ ❤ ✭ s❀ ♣ ✮✮ Offline: attacker can check guesses internally Block pre-computed tables and equality inferences Salt must also have enough entropy Specialized password lists more effective than literal Deliberately expensive hash function dictionaries AKA password-based key derivation function (PBKDF) Also generation algorithms (s ✦ $, etc.) Requirement for time and/or space ✘ 25% of passwords consistently vulnerable

Password usability Backup authentication Desire: unassisted recovery from forgotten password User compliance can be a major challenge Fall back to other presumed-authentic channel Often caused by unrealistic demands Email, cell phone Distributed random passwords usually unrealistic Harder to forget (but less secret) shared information Password aging: not too frequently Mother’s maiden name, first pet’s name Never have a fixed default password in a product Brittle: ask Sarah Palin or Mat Honan Centralized authentication Biometric authentication Authenticate by a physical body attribute Enterprise-wide (e.g., UMN ID) ✰ Hard to lose Anderson: Microsoft Passport ✲ Hard to reset Today: Facebook Connect, Google ID ✲ Inherently statistical May or may not be single-sign-on (SSO) ✲ Variation among people Example biometrics Error rates: ROC curve (Handwritten) signatures Fingerprints, hand geometry Face and voice recognition Iris codes Outline Note to early readers OS security: protection and isolation OS security: authentication This is the section of the slides most likely to change in the final version Announcements intermission If class has already happened, make sure you have Basics of access control the latest slides for announcements Unix-style access control

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

Interpretation of mode bits Directory mode bits File also has one user and group ID Same bits, slightly different interpretation Choose one set of bits Read: list contents (e.g., ❧s ) If users match, use user bits If subject is in the group, use group bits Write: add or delete files Otherwise, use other bits Execute: traverse Note no fallback, so can stop yourself or have X but not R means: have to know the names negative groups But usually, ❖ ✒ ● ✒ ❯ Process UIDs and s❡t✉✐❞✭✷✮ Setuid programs, different UIDs If 04000 “setuid” bit set, newly exec’d process will UID is inherited by child processes, and an take UID of its file owner unprivileged process can’t change it Other side conditions, like process not traced But there are syscalls root can use to change the Specifically the effective UID is changed, while the UID, starting with s❡t✉✐❞ real UID is unchanged E.g., login program, SSH server Shows who called you, allows switching back More different UIDs Setgid, games Two mechanisms for temporary switching: Swap real UID and effective UID (BSD) Setgid bit 02000 mostly analogous to setuid Remember saved UID , allow switching to it (System V) But note no supergroup, so UID 0 is still special Modern systems support both mechanisms at the Classic application: setgid ❣❛♠❡s for managing same time high-score files Linux only: file-system UID Once used for NFS servers, now mostly obsolete Special case: ✴t♠♣ Special case: group inheritance When using group to manage permissions, want a We’d like to allow anyone to make files in ✴t♠♣ whole tree to have a single group So, everyone should have write permission When 02000 bit set, newly created entries with But don’t want Alice deleting Bob’s files have the parent’s group (Historic BSD behavior) Solution: “sticky bit” 01000 Also, directories will themselves inherit 02000

Other permission rules Non-checks File permissions on st❛t Only file owner or root can change permissions File permissions on link, unlink, rename Only root can change file owner File permissions on read, write Former System V behavior: “give away ❝❤♦✇♥ ” Parent directory permissions generally Setuid/gid bits cleared on ❝❤♦✇♥ Except traversal Set owner first, then enable setuid I.e., permissions not automatically recursive “POSIX” ACLs ACL legacy interactions Based on a withdrawn standardization Hard problem: don’t break security of legacy code More flexible permissions, still fairly Unix-like Suggests: “fail closed” Contrary pressure: don’t want to break functionality Multiple user and group entries Suggests: “fail open” Decision still based on one entry POSIX ACL design: old group permission bits are a Default ACLs: generalize group inheritance mask on all novel permissions Command line: ❣❡t❢❛❝❧ , s❡t❢❛❝❧ “POSIX” “capabilities” Privilege escalation dangers Many pieces of the root privilege are enough to Divide root privilege into smaller ( ✘ 35) pieces regain the whole thing Access to files as UID 0 Note: not real capabilities ❈❆P ❉❆❈ ❖❱❊❘❘■❉❊ First runtime only, then added to FS similar to setuid ❈❆P ❋❖❲◆❊❘ ❈❆P ❙❨❙ ▼❖❉❯▲❊ Motivating example: ♣✐♥❣ ❈❆P ▼❑◆❖❉ Also allows permanent disabling ❈❆P P❚❘❆❈❊ ❈❆P ❙❨❙ ❆❉▼■◆ ( ♠♦✉♥t ) Legacy interaction dangers Next time Object capability systems Former bug: take away capability to drop privileges Mandatory access control Use of temporary files by no-longer setuid programs Information-flow security For more details: “Exploiting capabilities”, Emeric Nasi