os security
play

OS Security CS 161: Computer Security Prof. Anthony D. Joseph - PowerPoint PPT Presentation

Access Control and OS Security CS 161: Computer Security Prof. Anthony D. Joseph January 29, 2014 Access Control Some resources (files, web pages, ) are sensitive. How do we limit who can access them? This is called the access


  1. Access Control and OS Security CS 161: Computer Security Prof. Anthony D. Joseph January 29, 2014

  2. Access Control • Some resources (files, web pages, …) are sensitive. • How do we limit who can access them? • This is called the access control problem

  3. Access Control Fundamentals • Subject = a user, process, … (someone who is accessing resources) • Object = a file, device, web page, … (a resource that can be accessed) • Policy = the restrictions we’ll enforce • access ( S , O ) = true if subject S is allowed to access object O

  4. Example • access (Alice, Alice’s wall) = true access (Alice, Bob’s wall) = true access (Alice, Charlie’s wall) = false • access (daw, /home/cs161/gradebook) = true access (Alice, /home/cs161/gradebook) = false

  5. Access Control Matrix • access ( S , O ) = true if subject S is allowed to access object O Alice’s wall Bob’s wall Charlie’s wall … Alice true true false Bob false true false …

  6. Permissions • We can have finer-grained permissions, e.g., read, write, execute. • access (daw, /cs161/grades/alice) = {read, write} access (alice, /cs161/grades/alice) = {read} access (bob, /cs161/grades/alice) = {} /cs161/grades/alice daw read, write alice read bob -

  7. Web security • Let’s talk about how this applies to web security…

  8. Structure of a web application (code) ! /login.php ! (code) ! controller ! database ! /friends.php ! (code) ! /search.php ! How should we (code) ! implement access /viewwall.php ! control policy? . ! . ! . !

  9. Option 1: Integrated Access Control record ! username " (code) ! /login.php ! access check " (code) ! controller ! database ! /friends.php ! access (code) ! check " Record username. /search.php ! Check policy at each access check " (code) ! place in code that accesses data. /viewwall.php ! . ! . ! . !

  10. Option 2: Centralized Enforcement record ! username " (code) ! /login.php ! access check " (code) ! controller ! database ! /friends.php ! (code) ! Record username. /search.php ! Database checks (code) ! policy for each data access. /viewwall.php ! . ! . ! . !

  11. Option 1: Integrated Access Option 2: Centralized Control Enforcement record ! usernam record ! e " username " (code) ! (code) ! /login.php ! /login.php ! access access check " check " (code) ! (code) ! controller ! database ! controller ! database ! /friends.php ! /friends.php ! access check " (code) ! (code) ! /search.php ! /search.php ! access check " (code) ! Record username. Which option (code) ! /viewwall.php ! Record username. Database checks . ! would you pick? . ! Check policy at each . ! /viewwall.php ! policy for each place in code that . ! Discuss. . ! data access. . ! accesses data.

  12. Analysis • Centralized enforcement might be less prone to error – All accesses are vectored through a central chokepoint, which checks access – If you have to add checks to each piece of code that accesses data, it’s easy to forget a check (and app will work fine in normal usage, until someone tries to access something they shouldn’t) • Integrated checks are occasionally more flexible

  13. Complete mediation • The principle: complete mediation • Ensure that all access to data is mediated by something that checks access control policy. – In other words: the access checks can’t be bypassed

  14. Reference monitor • A reference monitor is responsible for mediating all access to data reference " subject ! object ! monitor ! • Subject cannot access data directly; operations must go through the reference monitor, which checks whether they’re OK

  15. Criteria for a reference monitor Ideally, a reference monitor should be: • Unbypassable: all accesses go through the reference monitor • Tamper-resistant: attacker cannot subvert or take control of the reference monitor (e.g., no code injection) • Verifiable: reference monitor should be simple enough that it’s unlikely to have bugs

  16. Example: OS memory protection • All memory accesses are mediated by memory controller, which enforces limits on what memory each process can access memory " CPU ! RAM ! controller ! Unbypassable? ✔

  17. Example: OS memory protection • All memory accesses are mediated by memory controller, which enforces limits on what memory each process can access memory " CPU ! RAM ! controller ! Tamper-resistant? ✔

  18. Example: OS memory protection • All memory accesses are mediated by memory controller, which enforces limits on what memory each process can access memory " CPU ! RAM ! controller ! Verifiable? ✔

  19. TCB • More broadly, the trusted computing base (TCB) is the subset of the system that has to be correct, for some security goal to be achieved – Example: the TCB for enforcing file access permissions includes the OS kernel and filesystem drivers • Ideally, TCBs should be unbypassable, tamper-resistant, and verifiable

  20. Privilege separation • How can we use these ideas to improve the security of software, so security bugs are less likely to be catastrophic?

  21. Privilege separation • How can we use these ideas to improve the security of software, so security bugs are less likely to be catastrophic? • Answer: privilege separation. Architect the software so it has a separate, small TCB. – Then any bugs outside the TCB will not be catastrophic

  22. Sandbox Sandbox Rendering Web browser Engine Rendering Engine Web Site ! Trusted ! Computing ! Base ! IPC Web Browser IPC HTML, ¡JS, ¡... Rendered ¡Bitmap Browser Rendering Kernel Engine Browser ¡Kernel HTML, ¡JS, ¡... Rendered ¡Bitmap Browser ¡Kernel “Drive-by malware”: malicious web page exploits a browser bug to read/write local files or infect them with a virus

  23. The Chrome browser Sandbox Goal: prevent “drive-by malware”, where a malicious Rendering Engine web page exploits a browser bug to read/write local files or infect them with a virus IPC Rendered ¡Bitmap HTML, ¡JS, ¡... TCB (for this property) ! Browser ¡Kernel

  24. The Chrome browser Sandbox Goal: prevent “drive-by malware”, where a malicious Rendering Engine web page exploits a browser bug to read/write local files or infect them with a virus IPC Rendered ¡Bitmap HTML, ¡JS, ¡... TCB (for this property) ! Browser ¡Kernel

  25. The Chrome browser 70% of vulnerabilities are Sandbox in the rendering engine. ! Rendering 1000K lines of code ! Engine Example: PNG, WMF, GDI+ ! rendering vulnerabilities in Windows OS ! IPC Rendered ¡Bitmap HTML, ¡JS, ¡... 700K lines of code ! Browser ¡Kernel

  26. Summary • Access control is a key part of security. • Privilege separation makes systems more robust: it helps reduce the impact of security bugs in your code. • Architect your system to make the TCB unbypassable, tamper-resistant, and verifiable (small).

  27. Coming Up … • Friday guest lecture: Malware • Homework 0 due Friday • C review session, Saturday, February 1 st , 2-4pm, 306 Soda

Recommend


More recommend