outline
play

Outline Multilevel and mandatory access control CSci 5271 - PDF document

Outline Multilevel and mandatory access control CSci 5271 Capability-based access control Introduction to Computer Security Announcements intermission Day 11: OS security: higher assurance Stephen McCamant OS trust and assurance University


  1. Outline Multilevel and mandatory access control CSci 5271 Capability-based access control Introduction to Computer Security Announcements intermission Day 11: OS security: higher assurance Stephen McCamant OS trust and assurance University of Minnesota, Computer Science & Engineering More Unix access control 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

  2. 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

  3. 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

  4. Chelsea Manning cables leak Outline Manning (n´ ee Bradley) was an Multilevel and mandatory access control intelligence analyst deployed to Iraq PC in a T-SCIF connected to SIPRNet Capability-based access control (Secret), air gapped Announcements intermission CD-RWs used for backup and software transfer OS trust and assurance Contrary to policy: taking such a More Unix access control CD-RW home in your pocket ❤tt♣✿✴✴✇✇✇✳❢❛s✳♦r❣✴s❣♣✴❥✉❞✴♠❛♥♥✐♥❣✴✵✷✷✽✶✸✲st❛t❡♠❡♥t✳♣❞❢ ACLs: no fine-grained subjects ACLs: ambient authority Subjects are a list of usernames All authority exists by virtue of identity maintained by a sysadmin Kernel automatically applies all available Unusual to have a separate subject for authority an application Authority applied incorrectly leads to Cannot easily subset access (sandbox) attacks Confused deputy problem (Object) capabilities Compiler writes to billing database A capability both designates a resource and provides authority to access it Compiler can produce debug output to Similar to an object reference user-specified file Unforgeable, but can copy and distribute Specify debug output to billing file, Typically still managed by the kernel disrupt billing

  5. Capability slogans (Miller et al.) Partial example: Unix FDs No designation without authority Authority to access a specific file Dynamic subject creation Managed by kernel on behalf of process Subject-aggregated authority mgmt. Can be passed between processes No ambient authority Though rare other than parent to child Composability of authorities Unix not designed to use pervasively Access-controlled delegation Dynamic resource creation Distinguish: password capabilities Revocation with capabilities Use indirection: give real capability via Bit pattern itself is the capability a pair of middlemen No centralized management ❆ ✦ ❇ via ❆ ✦ ❋ ✦ ❘ ✦ ❇ Modern example: authorization using Retain capability to tell ❘ to drop cryptographic certificates capability to ❇ Depends on composability Confinement with capabilities OKL4 and seL4 Commercial and research microkernels ❆ cannot pass a capability to ❇ if it Recent versions of OKL4 use capability cannot communicate with ❆ at all design from seL4 Disconnected parts of the capability Used as a hypervisor, e.g. underneath graph cannot be reconnected paravirtualized Linux Depends on controlled delegation and Shipped on over 1 billion cell phones data/capability distinction

  6. Joe-E and Caja Outline Multilevel and mandatory access control Dialects of Java and JavaScript (resp.) Capability-based access control using capabilities for confined execution E.g., of JavaScript in an advertisement Announcements intermission Note reliance on Java and JavaScript OS trust and assurance type safety More Unix access control Deadlines reminder Midterm exam Monday Usual class time and location Covers up through today’s lecture Tonight: Project progress reports Mix of short-answer and exercise-like Thursday: Ex. 2 questions Friday: HA1 attack(s) 5 (extra credit) Open books/notes/printouts, no Monday: midterm computers or other electronics Sample exams w/solutions (2013-2015) posted Outline Trusted and trustworthy Multilevel and mandatory access control Part of your system is trusted if its Capability-based access control failure can break your security Thus, OS is almost always trusted Announcements intermission Real question: is it trustworthy? OS trust and assurance Distinction not universally observed: trusted boot, Trusted Solaris, etc. More Unix access control

  7. Trusted (I/O) path Minimizing trust How do you know you’re talking to the Kernel ✦ microkernel ✦ nanokernel right software? Reference monitor concept And no one is sniffing the data? TCB size: measured relative to a policy Example: Trojan login screen goal Or worse: unlock screensaver with root Reference monitor ✒ TCB password But hard to build monitor for all goals Origin of “Press Ctrl-Alt-Del to log in” How to gain assurance Evaluation / certification Testing and review performed by an Use for a long time independent party Testing Goal: separate incentives, separate Code / design review accountability Third-party certification Compare with financial auditing Formal methods / proof Watch out for: form over substance, misplaced incentives Orange book OS evaluation Common Criteria International standard and agreement Trusted Computer System Evaluation for IT security certification Criteria Certification against a protection profile , D. Minimal protection and evaluation assurance level EAL 1-7 C. Discretionary protection Evaluation performed by C2 adds, e.g., secure audit over C1 B. Mandatory protection non-government labs B1 ❁ B2 ❁ B3: stricter classic MLS Up to EAL 4 automatically A. Verified protection cross-recognized

  8. Common Criteria, Anderson’s view Formal methods and proof Many profiles don’t specify the right Can math come to the rescue? things OSes evaluated only in unrealistic Checking design vs. implementation environments Automation possible only with other E.g., unpatched Windows XP with no tradeoffs network attacks E.g., bounded size model “Corruption, Manipulation, and Inertia” Pernicious innovation: evaluation paid for Starting to become possible: by vendor machine-checked proof Labs beholden to national security apparatus Proof and complexity Some hopeful proof results seL4 microkernel (SOSP’09 and Formal proof is only feasible for ongoing) programs that are small and elegant 7.5 kL C, 200 kL proof, 160 bugs fixed, 25 If you honestly care about assurance, person years you want your TCB small and elegant CompCert C-subset compiler (PLDI’06 anyway and ongoing) Should provability further guide design? RockSalt SFI verifier (PLDI’12) Outline Special case: ✴t♠♣ Multilevel and mandatory access control We’d like to allow anyone to make files Capability-based access control in ✴t♠♣ So, everyone should have write Announcements intermission permission OS trust and assurance But don’t want Alice deleting Bob’s files Solution: “sticky bit” 01000 More Unix access control

Recommend


More recommend