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 OS defensive design and security basics B. username Stephen McCamant C. executable inode University of Minnesota, Computer Science & Engineering D. program name E. UID Outline Be careful with temporary files Secure use of the OS, cont’d Bernstein’s perspective Create files exclusively with tight permissions and never reopen them Techniques for privilege separation See detailed recommendations in Wheeler OS security: protection and isolation Not quite good enough: reopen and check matching OS security: authentication device and inode Fails with sufficiently patient attack Basics of access control Unix-style access control Give up privileges Whitelist environment variables Using appropriate combinations of s❡t✯✐❞ functions Can change the behavior of called program in Alas, details differ between Unix variants unexpected ways Best: give up permanently Decide which ones are necessary Second best: give up temporarily As few as possible Detailed recommendations: Setuid Demystified Save these, remove any others (USENIX’02) Outline Historical background Secure use of the OS, cont’d Traditional Unix MTA: Sendmail (BSD) Bernstein’s perspective Monolithic setuid root program Techniques for privilege separation Designed for a more trusting era In mid-90s, bugs seemed endless OS security: protection and isolation Spurred development of new, security-oriented OS security: authentication replacements Basics of access control Bernstein’s qmail Venema et al.’s Postfix Unix-style access control

Distinctive qmail features Ineffective privilege separation Example: prevent Netscape DNS helper from accessing local file system Single, security-oriented developer Before: bug in DNS code Architecture with separate programs and UIDs ✦ read user’s private files Replacements for standard libraries After: bug in DNS code Deliveries into directories rather than large files ✦ inject bogus DNS results ✦ man-in-the-middle attack ✦ read user’s private web data Effective privilege separation Eliminating bugs Transformations with constrained I/O Enforce explicit data flow General argument: worst adversary can do is control Simplify integer semantics output Avoid parsing Which is just the benign functionality MTA header parsing (Sendmail bug) Generalize from errors to inputs ❥♣❡❣t♦♣♥♠ inside ①❧♦❛❞✐♠❛❣❡ Eliminating code The “qmail security guarantee” $500, later $1000 offered for security bug Identify common functions Never paid out Automatically handle errors Issues proposed: Reuse network tools Memory exhaustion DoS Reuse access controls Overflow of signed integer indexes Reuse the filesystem Defensiveness does not encourage more submissions qmail today Outline Secure use of the OS, cont’d Originally had terms that prohibited modified Bernstein’s perspective redistribution Techniques for privilege separation Now true public domain OS security: protection and isolation Latest release from Bernstein: 1998; netqmail: 2007 OS security: authentication Does not have large market share Basics of access control All MTAs, even Sendmail, are more secure now Unix-style access control

Restricted languages SFI Software-based Fault Isolation Main application: code provided by untrusted parties Instruction-level rewriting like (but predates) CFI Packet filters in the kernel Limit memory stores and sometimes loads JavaScript in web browsers Can’t jump out except to designated points Also Java, Flash ActionScript, etc. E.g., Google Native Client Separate processes System-call interposition Trusted process examines syscalls made by OS (and hardware) isolate one process from another untrusted Pay overhead for creation and communication Implement via ♣tr❛❝❡ (like strace, gdb) or via kernel System call interface allows many possibilities for change mischief Easy policy: deny Interposition challenges Separate users Argument values can change in memory (TOCTTOU) Reuse OS facilities for access control OS objects can change (TOCTTOU) Unit of trust: program or application How to get canonical object identifiers? Older example: qmail Interposer must accurately model kernel behavior Newer example: Android Details: Garfinkel (NDSS’03) Limitation: lots of things available to any user ❝❤r♦♦t OS-enabled containers Unix system call to change root directory One kernel, but virtualizes all namespaces Restrict/virtualize file system access FreeBSD jails, Linux LXC, Solaris zones, etc. Only available to root Quite robust, but the full, fixed, kernel is in the TCB Does not isolate other namespaces

(System) virtual machines Virtual machine designs Presents hardware-like interface to an untrusted (Type 1) hypervisor: ‘superkernel’ underneath VMs kernel Hosted: regular OS underneath VMs Strong isolation, full administrative complexity Paravirtualizaion: modify kernels in VMs for ease of I/O interface looks like a network, etc. virtualization Virtual machine technologies Modern example: Chrom(ium) Separates “browser kernel” from less-trusted “rendering engine” Hardware based: fastest, now common Pragmatic, keeps high-risk components together Partial translation: e.g., original VMware Experimented with various Windows and Linux sandboxing techniques Full emulation: e.g. QEMU proper Blocked 70% of historic vulnerabilities, not all new Slowest, but can be a different CPU architecture ones ❤tt♣✿✴✴s❡❝❧❛❜✳st❛♥❢♦r❞✳❡❞✉✴✇❡❜s❡❝✴❝❤r♦♠✐✉♠✴ Outline OS security topics Secure use of the OS, cont’d Bernstein’s perspective Resource protection Techniques for privilege separation Process isolation OS security: protection and isolation User authentication OS security: authentication Access control Basics of 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 Secure use of the OS, cont’d Bernstein’s perspective Supervisor (kernel) mode: all instructions available Techniques for privilege separation User mode: no hardware or VM control instructions OS security: protection and isolation Only way to switch to kernel mode is specified entry point OS security: authentication Also generalizes to multiple “rings” Basics of access control 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