Outline OS protection and isolation (cont’d) CSci 5271 OS security: authentication Introduction to Computer Security Basics of access control OS authentication and access control (combined lecture) Announcements, Ex. 1 debrief Stephen McCamant Multilevel and mandatory access control University of Minnesota, Computer Science & Engineering Capability-based access control 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 protection and isolation (cont’d) Supervisor (kernel) mode: all OS security: authentication instructions available User mode: no hardware or VM control Basics of access control instructions Announcements, Ex. 1 debrief Only way to switch to kernel mode is Multilevel and mandatory access control specified entry point Also generalizes to multiple “rings” Capability-based 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 Dictionary attacks Better password hashing Generate random salt s , store Online: send guesses to server ✭ s❀ ❤ ✭ s❀ ♣ ✮✮ Offline: attacker can check guesses Block pre-computed tables and equality internally inferences Specialized password lists more Salt must also have enough entropy effective than literal dictionaries Deliberately expensive hash function Also generation algorithms (s ✦ $, etc.) AKA password-based key derivation ✘ 25% of passwords consistently function (PBKDF) Requirement for time and/or space vulnerable
Password usability Backup authentication Desire: unassisted recovery from User compliance can be a major forgotten password challenge Fall back to other presumed-authentic Often caused by unrealistic demands channel Distributed random passwords usually Email, cell phone unrealistic Harder to forget (but less secret) Password aging: not too frequently shared information Never have a fixed default password in Mother’s maiden name, first pet’s name a product Brittle: ask Sarah Palin or Mat Honan Centralized authentication Biometric authentication Authenticate by a physical body Enterprise-wide (e.g., UMN ID) attribute Anderson: Microsoft Passport ✰ Hard to lose Today: Facebook Connect, Google ID ✲ Hard to reset May or may not be single-sign-on ✲ Inherently statistical (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 protection and isolation (cont’d) OS security: authentication Decision-making aspect of OS Should subject ❙ (user or process) be Basics of access control allowed to access object (e.g., file) ❖ ? Announcements, Ex. 1 debrief Complex, since admin must specify Multilevel and mandatory access control what should 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 Convenient to store with object Bob rw - rx E.g., Unix file permissions Carol r - rx Rows: capabilities Convenient to store by subject E.g., Unix file descriptors Groups/roles Outline OS protection and isolation (cont’d) Simplify by factoring out commonality OS security: authentication Before: users have permissions After: users have roles, roles have Basics of access control permissions Announcements, Ex. 1 debrief Simple example: Unix groups Multilevel and mandatory access control Complex versions called role-based access control (RBAC) Capability-based access control
Reversing the stack Payment app ✈♦✐❞ ♣❛②♠❡♥t✭❝❤❛r ✯♥❛♠❡✱ ✐♥t ❛♠♦✉♥t❴❥♣②✱ ✈♦✐❞ ❢✉♥❝✭❝❤❛r ✯str✮ ④ ❝❤❛r ✯♣✉r♣♦s❡✮ ④ ❝❤❛r ❜✉❢❬✶✷✽❪❀ ❢❧♦❛t ❛♠♦✉♥t❴✉s❞ ❂ ❛♠♦✉♥t❴❥♣②✴✶✵✾✳✷❀ str❝♣②✭❜✉❢✱ str✮❀ ❝❤❛r ♠❡♠♦❬✸✷❪❀ str❝♣②✭♠❡♠♦✱ ✧P❛②♠❡♥t ❢♦r✿ ✧✮❀ ❞♦❴s♦♠❡t❤✐♥❣✭✮❀ str❝❛t✭♠❡♠♦✱ ♣✉r♣♦s❡✮❀ r❡t✉r♥❀ ✇r✐t❡❴❝❤❡❝❦✭♥❛♠❡✱ ❛♠♦✉♥t❴✉s❞✱ ♠❡♠♦✮❀ ⑥ ⑥ Reverse range Deadlines reminder ✈♦✐❞ r❡✈❡rs❡❴r❛♥❣❡✭✐♥t ✯❛✱ ✐♥t ❢r♦♠✱ ✐♥t t♦✮ ④ ✐♥t ✯♣ ❂ ✫❛❬❢r♦♠❪❀ ✐♥t ✯q ❂ ✫❛❬t♦❪❀ Yesterday: Project progress reports ✇❤✐❧❡ ✭✦✭♣ ❂❂ q ✰ ✶ ⑤⑤ ♣ ❂❂ q ✰ ✷✮✮ ④ Tomorrow: Ex. 2 ✯♣ ✰❂ ✯q❀ ✯q ❂ ✯♣ ✲ ✯q❀ Week from today: midterm ✯♣ ❂ ✯♣ ✲ ✯q❀ ♣✰✰❀ q✲✲❀ ⑥ ⑥ Outline MAC vs. DAC Discretionary access control (DAC) OS protection and isolation (cont’d) Users mostly decide permissions on their OS security: authentication own files If you have information, you can pass it on Basics of access control to anyone E.g., traditional Unix file permissions Announcements, Ex. 1 debrief Mandatory access control (MAC) Multilevel and mandatory access control Restrictions enforced regardless of subject choices Capability-based access control Typically specified by an administrator
Motivation: it’s classified Motivation: system integrity Government defense and intelligence Limit damage if a network server agencies use classification to restrict application is compromised access to information Unix DAC is no help if server is root E.g.: Unclassified, Confidential, Secret, Limit damage from Top Secret browser-downloaded malware Multilevel Secure (MLS) systems first Windows DAC is no help if browser is developed to support mixing “administrator” user classification levels under timesharing Bell-LaPadula, linear case High watermark property State-machine-like model developed for US DoD in 1970s Dynamic implementation of BLP 1. A subject at one level may not read a Process has security level equal to resource at a higher level highest file read Simple security property, “no read up” Written files inherit this level 2. A subject at one level may not write a resource at a lower level * property, “no write down” Biba and low watermark Information-flow perspective Confidentiality: secret data should not Inverting a confidentiality policy gives flow to public sinks an integrity one Integrity: untrusted data should not flow Biba: no write up, no read down to critical sinks Low watermark policy Watermark policies are process-level BLP ❫ Biba ✮ levels are isolated conservative abstractions
Covert channels Multilateral security / compartments In classification, want finer divisions Problem: conspiring parties can misuse based on need-to-know other mechanisms to transmit information Also, selected wider sharing (e.g., with Storage channel: writable shared state allied nations) E.g., screen brightness on mobile phone Many other applications also have this Timing channel: speed or ordering of character events Anderson’s example: medical data E.g., deliberately consume CPU time How to adapt BLP-style MAC? Partial orders and lattices Subset lattice example ✔ on integers is a total order Reflexive, antisymmetric, transitive, ❛ ✔ ❜ or ❜ ✔ ❛ Dropping last gives a partial order A lattice is a partial order plus operators for: Least upper bound or join t Greatest lower bound or meet ✉ Example: subsets with ✒ , ❬ , ❭ Subset lattice example Lattice model Generalize MLS levels to elements in a lattice BLP and Biba work analogously with lattice ordering No access to incomparable levels Potential problem: combinatorial explosion of compartments
Classification lattice example Lattice BLP example Another notation MLS operating systems Faculty 1970s timesharing, including Multics ✦ (Faculty, ❄ ) “Trusted” versions of commercial Unix Faculty//5271 (e.g. Solaris) ✦ (Faculty, ❢ ✺✷✼✶ ❣ ) SELinux (called “type enforcement”) Faculty//5271//8271 Integrity protections in Windows Vista ✦ (Faculty, ❢ ✺✷✼✶❀ ✽✷✼✶ ❣ ) and later Multi-VM systems Air gaps, pumps, and diodes The lack of a connection between One (e.g., Windows) VM for each networks of different levels is called an security level air gap More trustworthy OS underneath A pump transfers data securely from provides limited interaction one network to another E.g., NSA NetTop: VMWare on SELinux A data diode allows information flow in Downside: administrative overhead only one direction
Recommend
More recommend
