Outline Secure use of the OS Bernstein’s perspective CSci 5271 Techniques for privilege separation Introduction to Computer Security Announcements intermission Day 9: OS security basics OS security: protection and isolation Stephen McCamant OS security: authentication University of Minnesota, Computer Science & Engineering Basics of access control Unix-style access control Be careful with temporary files Give up privileges Using appropriate combinations of Create files exclusively with tight s❡t✯✐❞ functions permissions and never reopen them Alas, details differ between Unix variants See detailed recommendations in Wheeler Best: give up permanently Not quite good enough: reopen and Second best: give up temporarily check matching device and inode Detailed recommendations: Setuid Fails with sufficiently patient attack Demystified (USENIX’02) Whitelist environment variables Outline Secure use of the OS Bernstein’s perspective Can change the behavior of called Techniques for privilege separation program in unexpected ways Announcements intermission Decide which ones are necessary OS security: protection and isolation As few as possible Save these, remove any others OS security: authentication Basics of access control Unix-style access control
Historical background Distinctive qmail features Traditional Unix MTA: Sendmail (BSD) Single, security-oriented developer Monolithic setuid root program Architecture with separate programs Designed for a more trusting era In mid-90s, bugs seemed endless and UIDs Spurred development of new, Replacements for standard libraries security-oriented replacements Deliveries into directories rather than Bernstein’s qmail large files Venema et al.’s Postfix Ineffective privilege separation Effective privilege separation Example: prevent Netscape DNS helper Transformations with constrained I/O from accessing local file system General argument: worst adversary can Before: bug in DNS code do is control output ✦ read user’s private files Which is just the benign functionality After: bug in DNS code MTA header parsing (Sendmail bug) ✦ inject bogus DNS results ✦ man-in-the-middle attack ❥♣❡❣t♦♣♥♠ inside ①❧♦❛❞✐♠❛❣❡ ✦ read user’s private web data Eliminating bugs Eliminating code Identify common functions Enforce explicit data flow Automatically handle errors Simplify integer semantics Reuse network tools Avoid parsing Reuse access controls Generalize from errors to inputs Reuse the filesystem
The “qmail security guarantee” qmail today Originally had terms that prohibited $500, later $1000 offered for security modified redistribution bug Now true public domain Never paid out Latest release from Bernstein: 1998; Issues proposed: netqmail: 2007 Memory exhaustion DoS Does not have large market share Overflow of signed integer indexes All MTAs, even Sendmail, are more Defensiveness does not encourage secure now more submissions Outline Restricted languages Secure use of the OS Bernstein’s perspective Main application: code provided by Techniques for privilege separation untrusted parties Announcements intermission Packet filters in the kernel OS security: protection and isolation JavaScript in web browsers OS security: authentication Also Java, Flash ActionScript, etc. Basics of access control Unix-style access control SFI Separate processes Software-based Fault Isolation OS (and hardware) isolate one process Instruction-level rewriting like (but from another predates) CFI Pay overhead for creation and Limit memory stores and sometimes communication loads System call interface allows many Can’t jump out except to designated possibilities for mischief points E.g., Google Native Client
System-call interposition Interposition challenges Argument values can change in Trusted process examines syscalls memory (TOCTTOU) made by untrusted OS objects can change (TOCTTOU) Implement via ♣tr❛❝❡ (like strace, gdb) How to get canonical object identifiers? or via kernel change Interposer must accurately model Easy policy: deny kernel behavior Details: Garfinkel (NDSS’03) Separate users ❝❤r♦♦t Reuse OS facilities for access control Unix system call to change root Unit of trust: program or application directory Older example: qmail Restrict/virtualize file system access Newer example: Android Only available to root Limitation: lots of things available to Does not isolate other namespaces any user OS-enabled containers (System) virtual machines One kernel, but virtualizes all Presents hardware-like interface to an namespaces untrusted kernel FreeBSD jails, Linux LXC, Solaris zones, Strong isolation, full administrative etc. complexity Quite robust, but the full, fixed, kernel is I/O interface looks like a network, etc. in the TCB
Virtual machine designs Virtual machine technologies (Type 1) hypervisor: ‘superkernel’ Hardware based: fastest, now common underneath VMs Partial translation: e.g., original VMware Hosted: regular OS underneath VMs Full emulation: e.g. QEMU proper Paravirtualizaion: modify kernels in VMs Slowest, but can be a different CPU architecture for ease of virtualization Modern example: Chrom(ium) Outline Secure use of the OS Separates “browser kernel” from less-trusted “rendering engine” Bernstein’s perspective Pragmatic, keeps high-risk components Techniques for privilege separation together Announcements intermission Experimented with various Windows and Linux sandboxing techniques OS security: protection and isolation Blocked 70% of historic vulnerabilities, OS security: authentication not all new ones Basics of access control ❤tt♣✿✴✴s❡❝❧❛❜✳st❛♥❢♦r❞✳❡❞✉✴✇❡❜s❡❝✴ Unix-style access control ❝❤r♦♠✐✉♠✴ Note to early readers HA1 week 4 Both OS/logic and memory safety bugs This is the section of the slides most still exist likely to change in the final version Remaining ones are complex for If class has already happened, make various reasons sure you have the latest slides for Also this week: design analysis and announcements suggestions
Outline OS security topics Secure use of the OS Bernstein’s perspective Resource protection Techniques for privilege separation Process isolation Announcements intermission User authentication OS security: protection and isolation Access control OS security: authentication Basics of access control Unix-style access control Protection and isolation Reference monitor Resource protection: prevent processes from accessing hardware Complete mediation: all accesses are Process isolation: prevent processes checked from interfering with each other Tamperproof: the monitor is itself Design: by default processes can do protected from modification neither Small enough to be thoroughly verified 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 Supervisor (kernel) mode: all Bernstein’s perspective instructions available Techniques for privilege separation User mode: no hardware or VM control Announcements intermission instructions OS security: protection and isolation Only way to switch to kernel mode is OS security: authentication 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, Something you have (e.g., smart card) researchers Something you are (biometrics) But familiar and near-zero cost of entry CAPTCHAs, time and location, . . . User-chosen passwords proliferate for Multi-factor authentication low-stakes web site authentication Password entropy Password hashing Model password choice as probabilistic Idea: don’t store password or process equivalent information Password ‘encryption’ is a If uniform, log ✷ ❥ ❙ ❥ long-standing misnomer Controls difficulty of guessing attacks E.g., Unix ❝r②♣t✭✸✮ Hard to estimate for user-chosen Presumably hard-to-invert function ❤ passwords Store only ❤ ✭ ♣ ✮ Length is an imperfect proxy
Recommend
More recommend
