Outline Multilevel and mandatory access control CSci 5271 - PDF document

Outline Multilevel and mandatory access control CSci 5271 Introduction to Computer Security Announcements intermission Day 10: OS security: access control Stephen McCamant Capability-based access control University of Minnesota, Computer Science & Engineering MAC vs. DAC Motivation: it’s classified Discretionary access control (DAC) Government defense and intelligence agencies use Users mostly decide permissions on their own files classification to restrict access to information If you have information, you can pass it on to anyone E.g., traditional Unix file permissions E.g.: Unclassified, Confidential, Secret, Top Secret Mandatory access control (MAC) Multilevel Secure (MLS) systems first developed to Restrictions enforced regardless of subject choices support mixing classification levels under timesharing Typically specified by an administrator Motivation: system integrity Bell-LaPadula, linear case State-machine-like model developed for US DoD in Limit damage if a network server application is 1970s compromised 1. A subject at one level may not read a resource at a Unix DAC is no help if server is root higher level Limit damage from browser-downloaded malware Simple security property, “no read up” 2. A subject at one level may not write a resource at a Windows DAC is no help if browser is “administrator” user lower level * property, “no write down” High watermark property Biba and low watermark Inverting a confidentiality policy gives an integrity Dynamic implementation of BLP one Process has security level equal to highest file read Biba: no write up, no read down Written files inherit this level Low watermark policy BLP ❫ Biba ✮ levels are isolated

Information-flow perspective Covert channels Confidentiality: secret data should not flow to public Problem: conspiring parties can misuse other sinks mechanisms to transmit information Storage channel: writable shared state Integrity: untrusted data should not flow to critical E.g., screen brightness on mobile phone sinks Timing channel: speed or ordering of events Watermark policies are process-level conservative E.g., deliberately consume CPU time abstractions Multilateral security / compartments Partial orders and lattices ✔ on integers is a total order In classification, want finer divisions based on Reflexive, antisymmetric, transitive, ❛ ✔ ❜ or ❜ ✔ ❛ need-to-know Dropping last gives a partial order Also, selected wider sharing (e.g., with allied nations) A lattice is a partial order plus operators for: Many other applications also have this character Least upper bound or join t Anderson’s example: medical data Greatest lower bound or meet ✉ How to adapt BLP-style MAC? Example: subsets with ✒ , ❬ , ❭ Subset lattice example Subset lattice example Lattice model Classification lattice example 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

Lattice BLP example Another notation Faculty ✦ (Faculty, ❄ ) Faculty//5271 ✦ (Faculty, ❢ ✺✷✼✶ ❣ ) Faculty//5271//8271 ✦ (Faculty, ❢ ✺✷✼✶❀ ✽✷✼✶ ❣ ) MLS operating systems Multi-VM systems One (e.g., Windows) VM for each security level 1970s timesharing, including Multics More trustworthy OS underneath provides limited “Trusted” versions of commercial Unix (e.g. Solaris) interaction SELinux (called “type enforcement”) E.g., NSA NetTop: VMWare on SELinux Integrity protections in Windows Vista and later Downside: administrative overhead Air gaps, pumps, and diodes Chelsea Manning cables leak Manning (n´ ee Bradley) was an intelligence analyst The lack of a connection between networks of deployed to Iraq different levels is called an air gap PC in a T-SCIF connected to SIPRNet (Secret), air A pump transfers data securely from one network to gapped another CD-RWs used for backup and software transfer A data diode allows information flow in only one Contrary to policy: taking such a CD-RW home in direction your pocket ❤tt♣✿✴✴✇✇✇✳❢❛s✳♦r❣✴s❣♣✴❥✉❞✴♠❛♥♥✐♥❣✴✵✷✷✽✶✸✲st❛t❡♠❡♥t✳♣❞❢ Outline Note to early readers This is the section of the slides most likely to change Multilevel and mandatory access control in the final version If class has already happened, make sure you have Announcements intermission the latest slides for announcements Capability-based access control In particular, the BCMTA vulnerability announcement is embargoed

Outline ACLs: no fine-grained subjects Multilevel and mandatory access control Subjects are a list of usernames maintained by a sysadmin Announcements intermission Unusual to have a separate subject for an application Cannot easily subset access (sandbox) Capability-based access control ACLs: ambient authority Confused deputy problem Compiler writes to billing database All authority exists by virtue of identity Compiler can produce debug output to Kernel automatically applies all available authority user-specified file Authority applied incorrectly leads to attacks Specify debug output to billing file, disrupt billing (Object) capabilities Capability slogans (Miller et al.) No designation without authority A capability both designates a resource and Dynamic subject creation provides authority to access it Subject-aggregated authority mgmt. Similar to an object reference No ambient authority Unforgeable, but can copy and distribute Composability of authorities Typically still managed by the kernel Access-controlled delegation Dynamic resource creation Partial example: Unix FDs Distinguish: password capabilities Authority to access a specific file Bit pattern itself is the capability Managed by kernel on behalf of process No centralized management Can be passed between processes Modern example: authorization using cryptographic Though rare other than parent to child certificates Unix not designed to use pervasively

Revocation with capabilities Confinement with capabilities ❆ cannot pass a capability to ❇ if it cannot Use indirection: give real capability via a pair of communicate with ❆ at all middlemen Disconnected parts of the capability graph cannot be ❆ ✦ ❇ via ❆ ✦ ❋ ✦ ❘ ✦ ❇ reconnected Retain capability to tell ❘ to drop capability to ❇ Depends on controlled delegation and data/capability Depends on composability distinction OKL4 and seL4 Joe-E and Caja Commercial and research microkernels Dialects of Java and JavaScript (resp.) using Recent versions of OKL4 use capability design from capabilities for confined execution seL4 E.g., of JavaScript in an advertisement Used as a hypervisor, e.g. underneath paravirtualized Note reliance on Java and JavaScript type safety Linux Shipped on over 1 billion cell phones Next time Techniques for higher assurance