Outline Capability-based access control CSci 5271 OS trust and - PDF document

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

Capability slogans (Miller et al.) Partial example: Unix FDs No designation with 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

Joe-E and Caja Outline Capability-based access control Dialects of Java and JavaScript (resp.) using capabilities for confined execution OS trust and assurance E.g., of JavaScript in an advertisement Assignment debrief and announcements Note reliance on Java and JavaScript type safety More Unix access control Trusted and trustworthy Trusted (I/O) path How do you know you’re talking to the Part of your system is trusted if its right software? failure can break your security And no one is sniffing the data? Thus, OS is almost always trusted Example: Trojan login screen Real question: is it trustworthy? Or worse: unlock screensaver with root Distinction not universally observed: password trusted boot, Trusted Solaris, etc. Origin of “Press Ctrl-Alt-Del to log in” Minimizing trust How to gain assurance Kernel ✦ microkernel ✦ nanokernel Use for a long time Reference monitor concept Testing TCB size: measured relative to a policy Code / design review goal Third-party certification Reference monitor ✒ TCB Formal methods / proof But hard to build monitor for all goals

Evaluation / certification Orange book OS evaluation Trusted Computer System Evaluation Testing and review performed by an Criteria independent party D. Minimal protection Goal: separate incentives, separate C. Discretionary protection accountability C2 adds, e.g., secure audit over C1 Compare with financial auditing B. Mandatory protection Watch out for: form over substance, B1 ❁ B2 ❁ B3: stricter classic MLS misplaced incentives A. Verified protection Common Criteria Common Criteria, Anderson’s view Many profiles don’t specify the right International standard and agreement things for IT security certification OSes evaluated only in unrealistic Certification against a protection profile , environments and evaluation assurance level EAL 1-7 E.g., unpatched Windows XP with no network attacks Evaluation performed by “Corruption, Manipulation, and Inertia” non-government labs Pernicious innovation: evaluation paid for Up to EAL 4 automatically by vendor Labs beholden to national security cross-recognized apparatus Formal methods and proof Proof and complexity Can math come to the rescue? Formal proof is only feasible for Checking design vs. implementation programs that are small and elegant Automation possible only with other If you honestly care about assurance, tradeoffs you want your TCB small and elegant E.g., bounded size model anyway Starting to become possible: Should provability further guide design? machine-checked proof

Some hopeful proof results Outline seL4 microkernel (SOSP’09 and Capability-based access control ongoing) 7.5 kL C, 200 kL proof, 160 bugs fixed, 25 OS trust and assurance person years CompCert C-subset compiler (PLDI’06 Assignment debrief and announcements and ongoing) More Unix access control RockSalt SFI verifier (PLDI’12) Exercise set 1 comments Silly function st❛t✭♣❛t❤♥❛♠❡✱ ✫❢✮❀ st❛t✭✧✴✇❤❛t✴❡✈❡r✧✱ ✫✇❡✮❀ ✐❢ ✭❢✳st❴❞❡✈ ❂❂ ✇❡✳st❴❞❡✈ ✫✫ ❢✳st❴✐♥♦ ❂❂ ✇❡✳st❴✐♥♦✮ ④ Net risk reduction: this is a formula, r❡t✉r♥❀ ⑥ know how to compute it r❢❞ ❂ ♦♣❡♥✭♣❛t❤♥❛♠❡✱ ❖❴❘❉❖◆▲❨✮❀ ❜✉❢ ❂ ♠❛❧❧♦❝✭❢✳st❴s✐③❡ ✲ ✶✮❀ ❵❣r❡♣ ✩✉s❡r♥❛♠❡❵ : I should have said r❡❛❞✭r❢❞✱ ❜✉❢✱ ❢✳st❴s✐③❡ ✲ ✶✮❀ ❝❧♦s❡✭r❢❞✮❀ two good ways to change the code st❛t✭♣❛t❤♥❛♠❡✱ ✫❢✮❀ ✐❢ ✭❢✳st❴❞❡✈ ❂❂ ✇❡✳st❴❞❡✈ ✫✫ ❢✳st❴✐♥♦ ❂❂ ✇❡✳st❴✐♥♦✮ ④ ✭ mod ✷ ✸✷ ✮ Solving ✶✸ ✁ ① ✑ ✶✵ r❡t✉r♥❀ ⑥ ✇❢❞ ❂ ♦♣❡♥✭♣❛t❤♥❛♠❡✱ ❖❴❲❘❖◆▲❨ ⑤ ❖❴❚❘❯◆❈✮❀ ✇r✐t❡✭✇❢❞✱ ❜✉❢✱ ❢✳st❴s✐③❡✲✶✮❀ ❝❧♦s❡✭✇❢❞✮❀ 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❞✱ ♠❡♠♦✮❀ ⑥ ⑥

Big- and little-endian Big- and little-endian Overwriting ✵①✶✷✸✹✺✻✼✽ with Overwriting ✵①✶✷✸✹✺✻✼✽ with ✧✳✳✳❆❆❆❆❆❭✵✧ : ✧✳✳✳❆❆❆❆❆❭✵✧ : ✵①✵✵✸✹✺✻✼✽ ✵①✶✷✸✹✺✻✵✵ ✵①✹✶✵✵✺✻✼✽ ✵①✶✷✸✹✵✵✹✶ ✵①✹✶✹✶✵✵✼✽ ✵①✶✷✵✵✹✶✹✶ ✵①✹✶✹✶✹✶✵✵ ✵①✵✵✹✶✹✶✹✶ ✵①✹✶✹✶✹✶✹✶ ✵①✹✶✹✶✹✶✹✶ Zip function BCVS vulnerabilities ❝❤❛r ✯③✐♣✭❝❤❛r ✯❛✱ ❝❤❛r ✯❜✮ ④ ❝❤❛r ✯r❡s✉❧t❀ Type 1: Buffer overflows and similar ✐♥t ❧❡♥✱ ✐❀ Some easy to spot, but hard to exploit ❧❡♥ ❂ str❧❡♥✭❛✮❀ r❡s✉❧t ❂ ♠❛❧❧♦❝✭✷✯❧❡♥✮❀ Type 2: Logic errors in running ❢♦r✭✐ ❂ ✵❀ ✐ ❁❂ ❧❡♥❀ ✐✰✰✮ ④ programs, file accesses, etc. r❡s✉❧t❬✷✯✐❪ ❂ ❛❬✐❪❀ Usually easier to exploit once found r❡s✉❧t❬✷✯✐✰✶❪ ❂ ❜❬✐❪❀ ⑥ r❡t✉r♥ r❡s✉❧t❀ ⑥ BCVS exploiting overflows BCVS design changes Avoid unnecessary changes to benign Make sure control flow reaches the functionality return Restricting length or character sets of Compensate for collateral damage arguments Though, what is the benign functionality? Find your shellcode Not a great candidate for privilege Writing shellcode separation