Outline Unix-style access control, contd CSci 5271 Multilevel and - PDF document

Outline Unix-style access control, cont’d CSci 5271 Multilevel and mandatory access control Introduction to Computer Security Access control, cont’d Announcements intermission Stephen McCamant Capability-based access control University of Minnesota, Computer Science & Engineering Side and covert channel basics “POSIX” ACLs ACL legacy interactions Based on a withdrawn standardization Hard problem: don’t break security of legacy code More flexible permissions, still fairly Unix-like Suggests: “fail closed” Contrary pressure: don’t want to break functionality Multiple user and group entries Suggests: “fail open” Decision still based on one entry POSIX ACL design: old group permission bits are a Default ACLs: generalize group inheritance mask on all novel permissions Command line: ❣❡t❢❛❝❧ , s❡t❢❛❝❧ “POSIX” “capabilities” Privilege escalation dangers Many pieces of the root privilege are enough to Divide root privilege into smaller ( ✘ 35) pieces regain the whole thing Access to files as UID 0 Note: not real capabilities ❈❆P ❉❆❈ ❖❱❊❘❘■❉❊ First runtime only, then added to FS similar to setuid ❈❆P ❋❖❲◆❊❘ Motivating example: ♣✐♥❣ ❈❆P ❙❨❙ ▼❖❉❯▲❊ ❈❆P ▼❑◆❖❉ Also allows permanent disabling ❈❆P P❚❘❆❈❊ ❈❆P ❙❨❙ ❆❉▼■◆ ( ♠♦✉♥t ) Legacy interaction dangers Outline Unix-style access control, cont’d Multilevel and mandatory access control Former bug: take away capability to drop privileges Use of temporary files by no-longer setuid programs Announcements intermission For more details: “Exploiting capabilities”, Emeric Nasi Capability-based access control Side and covert channel basics

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 higher level Unix DAC is no help if server is root 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 Multilateral security / compartments In classification, want finer divisions based on Confidentiality: secret data should not flow to public need-to-know sinks Also, selected wider sharing (e.g., with allied nations) Integrity: untrusted data should not flow to critical sinks Many other applications also have this character Anderson’s example: medical data Watermark policies are process-level conservative abstractions 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 (e.g. Solaris) Faculty//5271 ✦ (Faculty, ❢ ✺✷✼✶ ❣ ) SELinux (called “type enforcement”) Faculty//5271//8271 Integrity protections in Windows Vista and later ✦ (Faculty, ❢ ✺✷✼✶❀ ✽✷✼✶ ❣ )

Multi-VM systems Air gaps, pumps, and diodes The lack of a connection between networks of One (e.g., Windows) VM for each security level different levels is called an air gap More trustworthy OS underneath provides limited A pump transfers data securely from one network to interaction another E.g., NSA NetTop: VMWare on SELinux A data diode allows information flow in only one Downside: administrative overhead direction Chelsea Manning cables leak Outline Unix-style access control, cont’d Manning (n´ ee Bradley) was an intelligence analyst deployed to Iraq Multilevel and mandatory access control PC in a T-SCIF connected to SIPRNet (Secret), air Announcements intermission gapped CD-RWs used for backup and software transfer Capability-based access control Contrary to policy: taking such a CD-RW home in Side and covert channel basics your pocket ❤tt♣✿✴✴✇✇✇✳❢❛s✳♦r❣✴s❣♣✴❥✉❞✴♠❛♥♥✐♥❣✴✵✷✷✽✶✸✲st❛t❡♠❡♥t✳♣❞❢ HA1 week 4 Exercise set 2 Both OS/logic and memory safety bugs still exist Posted this morning, due next Wednesday Remaining ones are complex for various reasons Covers defensive programming and OS security Also this week: design analysis and suggestions Indicate your groups in Canvas Project progress Outline Unix-style access control, cont’d Multilevel and mandatory access control Individual progress reports due tonight Announcements intermission Next meetings later in October Capability-based access control Side and covert channel basics

ACLs: no fine-grained subjects ACLs: ambient authority Subjects are a list of usernames maintained by a All authority exists by virtue of identity sysadmin Kernel automatically applies all available authority Unusual to have a separate subject for an application Authority applied incorrectly leads to attacks Cannot easily subset access (sandbox) Confused deputy problem (Object) capabilities A capability both designates a resource and Compiler writes to billing database 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, disrupt billing Typically still managed by the kernel 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 a pair of Bit pattern itself is the capability middlemen No centralized management ❆ ✦ ❇ via ❆ ✦ ❋ ✦ ❘ ✦ ❇ Modern example: authorization using cryptographic Retain capability to tell ❘ to drop capability to ❇ certificates Depends on composability

Confinement with capabilities OKL4 and seL4 Commercial and research microkernels ❆ cannot pass a capability to ❇ if it cannot Recent versions of OKL4 use capability design from communicate with ❆ at all seL4 Disconnected parts of the capability graph cannot be Used as a hypervisor, e.g. underneath paravirtualized reconnected Linux Depends on controlled delegation and data/capability Shipped on over 1 billion cell phones distinction Joe-E and Caja Outline Unix-style access control, cont’d Dialects of Java and JavaScript (resp.) using Multilevel and mandatory access control capabilities for confined execution Announcements intermission E.g., of JavaScript in an advertisement Note reliance on Java and JavaScript type safety Capability-based access control Side and covert channel basics More confidentiality problems Side channel vs. covert channel Careful access control prevents secret data from Side channel: information leaks from an “leaking” though normal OS-mediated unsuspecting victim communication channels Covert channel: information intentionally leaked by a adversarial sender Residual problem: channels not designed for Violating an isolation property communication Sender and receiver work together A major theme of ongoing computer security Distinction sometimes unclear or not observed research Kinds of channels Classic software covert channels Software channels: undesired feature of program Storage channel: writable shared state behaviors E.g., screen brightness on mobile phone Physical channels: channels mediated by the real Timing channel: speed or ordering of events world E.g., deliberately consume CPU time Hardware channels: undesired feature of hardware behaviors