Outline OS security: authentication, cont’d Basics of access control CSci 5271 Introduction to Computer Security Announcements intermission OS security: access control Unix-style access control Stephen McCamant Multilevel and mandatory access control University of Minnesota, Computer Science & Engineering Capability-based access control Passwords: love to hate Password entropy Model password choice as probabilistic process Many problems for users, sysadmins, researchers If uniform, log ✷ ❥ ❙ ❥ But familiar and near-zero cost of entry Controls difficulty of guessing attacks User-chosen passwords proliferate for low-stakes Hard to estimate for user-chosen passwords web site authentication Length is an imperfect proxy Password hashing Dictionary attacks Online: send guesses to server Idea: don’t store password or equivalent information Offline: attacker can check guesses internally Password ‘encryption’ is a long-standing misnomer Specialized password lists more effective than literal E.g., Unix ❝r②♣t✭✸✮ dictionaries Presumably hard-to-invert function ❤ Also generation algorithms (s ✦ $, etc.) Store only ❤ ✭ ♣ ✮ ✘ 25% of passwords consistently vulnerable Better password hashing Backup authentication Desire: unassisted recovery from forgotten password Generate random salt s , store ✭ s❀ ❤ ✭ s❀ ♣ ✮✮ Fall back to other presumed-authentic channel Block pre-computed tables and equality inferences Salt must also have enough entropy Email, cell phone Deliberately expensive hash function Harder to forget (but less secret) shared information AKA password-based key derivation function (PBKDF) Mother’s maiden name, first pet’s name Requirement for time and/or space 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 Mechanism and policy OS security: authentication, cont’d Decision-making aspect of OS Basics of access control Should subject ❙ (user or process) be allowed to Announcements intermission access object (e.g., file) ❖ ? Unix-style access control Complex, since admin must specify what should Multilevel and mandatory access control happen Capability-based 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: authentication, cont’d Simplify by factoring out commonality Basics of access control Before: users have permissions Announcements intermission After: users have roles, roles have permissions Unix-style access control Simple example: Unix groups Complex versions called role-based access control Multilevel and mandatory access control (RBAC) Capability-based access control Multiple BCMTA vulnerabilities found! Changes coming in BCMTA 2.3 Avoid unneeded buffer in t❡r♠ ❝♦♣② Buffer overrun in t❡r♠ ❝♦♣② Use str❧❝♣② when constructing ✳❢♦r✇❛r❞ file Buffer overrun in constructing the ✳❢♦r✇❛r❞ file location location Check ownership of delivery file Writing message to file allowed write to system file Remove optimizations ❛❝❝❡❧❡r❛t❡❞ str❝♣② was less secure One more delivery feature Release planned for this evening Outline UIDs and GIDs OS security: authentication, cont’d To kernel, users and groups are just numeric Basics of access control identifiers Names are a user-space nicety Announcements intermission E.g., ✴❡t❝✴♣❛ss✇❞ mapping Unix-style access control Historically 16-bit, now 32 Multilevel and mandatory access control User 0 is the special superuser r♦♦t Exempt from all access control checks Capability-based access control File mode bits Interpretation of mode bits File also has one user and group ID Core permissions are 9 bits, three groups of three Choose one set of bits If users match, use user bits Read, write, execute for user, group, other If subject is in the group, use group bits ❧s format: r✇① r✲① r✲✲ Otherwise, use other bits Octal format: 0754 Note no fallback, so can stop yourself or have negative groups But usually, ❖ ✒ ● ✒ ❯
Directory mode bits Process UIDs and s❡t✉✐❞✭✷✮ Same bits, slightly different interpretation UID is inherited by child processes, and an unprivileged process can’t change it Read: list contents (e.g., ❧s ) But there are syscalls root can use to change the Write: add or delete files 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 switching: If 04000 “setuid” bit set, newly exec’d process will Swap real UID and effective UID (BSD) take UID of its file owner Remember saved UID , allow switching to it (System V) Other side conditions, like process not traced Modern systems support both mechanisms at the Specifically the effective UID is changed, while the same time real UID is unchanged Linux only: file-system UID Shows who called you, allows switching back Once used for NFS servers, now mostly obsolete Setgid, games Special case: ✴t♠♣ We’d like to allow anyone to make files in ✴t♠♣ Setgid bit 02000 mostly analogous to setuid So, everyone should have write permission But note no supergroup, so UID 0 is still 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 permissions, want a Only file owner or root can change permissions whole tree to have a single group Only root can change file owner When 02000 bit set, newly created entries with Former System V behavior: “give away ❝❤♦✇♥ ” have the parent’s group Setuid/gid bits cleared on ❝❤♦✇♥ (Historic BSD behavior) Set owner first, then enable setuid Also, directories will themselves inherit 02000
Non-checks “POSIX” ACLs Based on a withdrawn standardization File permissions on st❛t More flexible permissions, still fairly Unix-like File permissions on link, unlink, rename Multiple user and group entries File permissions on read, write Decision still based on one entry Parent directory permissions generally Default ACLs: generalize group inheritance Except traversal I.e., permissions not automatically recursive Command line: ❣❡t❢❛❝❧ , s❡t❢❛❝❧ ACL legacy interactions “POSIX” “capabilities” Hard problem: don’t break security of legacy code Divide root privilege into smaller ( ✘ 35) pieces Suggests: “fail closed” Note: not real capabilities Contrary pressure: don’t want to break functionality First runtime only, then added to FS similar to setuid Suggests: “fail open” Motivating example: ♣✐♥❣ POSIX ACL design: old group permission bits are a Also allows permanent disabling mask on all novel permissions Privilege escalation dangers Legacy interaction dangers Many pieces of the root privilege are enough to regain the whole thing Former bug: take away capability to drop privileges Access to files as UID 0 ❈❆P ❉❆❈ ❖❱❊❘❘■❉❊ Use of temporary files by no-longer setuid programs ❈❆P ❋❖❲◆❊❘ For more details: “Exploiting capabilities”, Emeric Nasi ❈❆P ❙❨❙ ▼❖❉❯▲❊ ❈❆P ▼❑◆❖❉ ❈❆P P❚❘❆❈❊ ❈❆P ❙❨❙ ❆❉▼■◆ ( ♠♦✉♥t ) Outline MAC vs. DAC OS security: authentication, cont’d Discretionary access control (DAC) Basics of access control Users mostly decide permissions on their own files If you have information, you can pass it on to anyone Announcements intermission E.g., traditional Unix file permissions Unix-style access control Mandatory access control (MAC) Restrictions enforced regardless of subject choices Multilevel and mandatory access control Typically specified by an administrator Capability-based access control
Recommend
More recommend
