OS Security 2009


Published on

OS Security 2009

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

OS Security 2009

  1. 1. Operating Systems and Security
  2. 2. OS Security <ul><li>OSs are large, complex programs </li></ul><ul><ul><li>Many bugs in any such program </li></ul></ul><ul><ul><li>We have seen that bugs can be security threats </li></ul></ul><ul><li>Here we are concerned with security provided by OS </li></ul><ul><ul><li>Not concerned with threat of bad OS software </li></ul></ul><ul><li>Concerned with OS as security enforcer </li></ul>
  3. 3. Introduction <ul><li>Operating systems provide the lowest layer of software visible to users </li></ul><ul><li>Operating systems are close to the hardware </li></ul><ul><li>– Often have complete hardware access </li></ul><ul><li>If the operating system isn’t protected, the machine isn’t protected </li></ul><ul><li>Flaws in the OS generally compromise all security at higher levels </li></ul>
  4. 4. Why Is OS Security So Important? <ul><li>The OS controls access to application memory </li></ul><ul><li>The OS controls scheduling of the processor </li></ul><ul><li>The OS ensures that users receive the resources they ask for </li></ul><ul><li>If the OS isn’t doing these things securely, practically anything can go wrong </li></ul><ul><li>So almost all other security systems must assume a secure OS at the bottom </li></ul>
  5. 5. OS Security Challenges <ul><li>Modern OS is multi-user and multi-tasking </li></ul><ul><li>OS must deal with </li></ul><ul><ul><li>Memory </li></ul></ul><ul><ul><li>I/O devices (disk, printer, etc.) </li></ul></ul><ul><ul><li>Programs, threads </li></ul></ul><ul><ul><li>Network issues </li></ul></ul><ul><ul><li>Data, etc. </li></ul></ul><ul><li>OS must protect processes from other processes and users from other users </li></ul><ul><ul><li>Whether accidental or malicious </li></ul></ul>
  6. 6. Single User Vs. Multiple User Machines <ul><li>The majority of today’s computers usually support a single user </li></ul><ul><li>– Sometimes one at a time, sometimes only one ever </li></ul><ul><li>Some computers are still multi-user </li></ul><ul><li>– Mainframes </li></ul><ul><li>– Servers </li></ul><ul><li>– Network-of-workstation machines </li></ul><ul><li>Single user machines often run multiple processes, though </li></ul>
  7. 7. Server Machines Vs. General Purpose Machines <ul><li>Most server machines provide only limited services </li></ul><ul><li>– Web page access </li></ul><ul><li>– File access </li></ul><ul><li>– DNS lookup </li></ul><ul><li>Security problems are simpler for them </li></ul>
  8. 8. Downloadable Code and Single User Machines <ul><li>Applets and other downloaded code should run in a constrained mode </li></ul><ul><li>Using access control on a finer granularity than the user </li></ul><ul><li>Essentially the same protection problem as multiple users </li></ul>
  9. 9. Mechanisms for Secure Operating Systems <ul><li>Most operating system security is based on separation </li></ul><ul><li>– Keep the bad guys away from the good stuff </li></ul><ul><li>– Since you don’t know who’s bad, separate most things </li></ul>
  10. 10. Separation Methods <ul><li>Physical separation </li></ul><ul><li>– Different machines </li></ul><ul><li>Temporal separation </li></ul><ul><li>– Same machine, different times </li></ul><ul><li>Logical separation </li></ul><ul><li>– HW/software enforcement </li></ul><ul><li>Cryptographic separation </li></ul>
  11. 11. The Problem of Sharing <ul><li>Separating stuff is actually pretty easy </li></ul><ul><li>The hard problem is allowing controlled sharing </li></ul><ul><li>How can the OS allow users to share exactly what they intend to share? </li></ul><ul><li>– In exactly the ways they intend </li></ul>
  12. 12. OS Security Functions <ul><li>Memory protection </li></ul><ul><ul><li>Protect memory from users/processes </li></ul></ul><ul><li>File protection </li></ul><ul><ul><li>Protect user and system resources </li></ul></ul><ul><li>Authentication </li></ul><ul><ul><li>Determines and enforce authentication results </li></ul></ul><ul><li>Authorization </li></ul><ul><ul><li>Determine and enforces access control </li></ul></ul>
  13. 13. Memory Protection <ul><li>Fundamental problem </li></ul><ul><ul><li>How to keep users/processes separate? </li></ul></ul><ul><li>Separation </li></ul><ul><ul><li>Physical separation  separate devices </li></ul></ul><ul><ul><li>Temporal separation  one at a time </li></ul></ul><ul><ul><li>Logical separation  with hardware/software </li></ul></ul><ul><ul><li>Cryptographic separation  make information unintelligible to outsider </li></ul></ul><ul><ul><li>Or any combination of the above </li></ul></ul>
  14. 14. Memory Protection <ul><li>Base/bounds register  lower and upper address limit </li></ul><ul><li>Assumes contiguous space </li></ul><ul><li>Like a Fence  users cannot cross a specified address </li></ul>
  15. 15. Memory Protection <ul><li>Tagging  specify protection of each address </li></ul><ul><ul><li>+ Extremely fine-grained protection </li></ul></ul><ul><ul><li>- High overhead  can be reduced by tagging sections instead of individual addresses </li></ul></ul><ul><li>More common is segmentation and/or paging </li></ul><ul><ul><li>Protection is not as flexible </li></ul></ul><ul><ul><li>But much more efficient </li></ul></ul>
  16. 16. Segmentation <ul><li>Divide memory into logical units, such as </li></ul><ul><ul><li>Single procedure </li></ul></ul><ul><ul><li>Data in one array, etc. </li></ul></ul><ul><li>Can enforce different access restrictions on different segments </li></ul><ul><li>Any segment can be placed in any memory location (if location is large enough) </li></ul><ul><li>OS keeps track of actual locations </li></ul>
  17. 17. Segmentation program memory
  18. 18. Segmentation <ul><li>OS can place segments anywhere </li></ul><ul><li>OS keeps track of segment locations as <segment,offset> </li></ul><ul><li>Segments can be moved in memory </li></ul><ul><li>Segments can move out of memory </li></ul><ul><li>All address references go thru OS </li></ul>
  19. 19. Segmentation Advantages <ul><li>Every address reference can be checked </li></ul><ul><ul><li>Possible to achieve complete mediation </li></ul></ul><ul><li>Different protection can be applied to different segments </li></ul><ul><li>Users can share access to segments </li></ul><ul><li>Specific users can be restricted to specific segments </li></ul>
  20. 20. Segmentation Disadvantages <ul><li>How to reference <segment,offset> ? </li></ul><ul><ul><li>OS must know segment size to verify access is within segment </li></ul></ul><ul><ul><li>But some segments can grow during execution (for example, dynamic memory allocation) </li></ul></ul><ul><ul><li>OS must keep track of variable segment sizes </li></ul></ul><ul><li>Memory fragmentation is also a problem </li></ul><ul><ul><li>Compacting memory changes tables </li></ul></ul><ul><li>A lot of work for the OS </li></ul><ul><li>More complex  more chance for mistakes </li></ul>
  21. 21. Paging <ul><li>Like segmentation, but fixed-size segments </li></ul><ul><li>Access via <page,offset> </li></ul><ul><li>Plusses and minuses </li></ul><ul><ul><li>+ Avoids fragmentation, improved efficiency </li></ul></ul><ul><ul><li>+ OS need not keep track of variable segment sizes </li></ul></ul><ul><ul><li>- No logical unity to pages </li></ul></ul><ul><ul><li>- What protection to apply to a given page? </li></ul></ul>
  22. 22. Paging program memory Page 1 Page 0 Page 2 Page 3 Page 4 Page 2 Page 1 Page 0 Page 3 Page 4
  23. 23. Protecting Interprocess Communications <ul><li>Operating systems provide various kinds of interprocess communications </li></ul><ul><li>– Messages </li></ul><ul><li>– Semaphores </li></ul><ul><li>– Shared memory </li></ul><ul><li>– Sockets </li></ul><ul><li>How can we be sure they’re used properly? </li></ul>
  24. 24. IPC Protection Issues <ul><li>How hard it is depends on what you’re worried about </li></ul><ul><li>For the moment, let’s say we’re worried about one process improperly using IPC to get info from another </li></ul><ul><li>– Process A wants to steal information from process B </li></ul><ul><li>How would process A do that? </li></ul>
  25. 25. Message Security Can process B use message based IPC to steal the secret?
  26. 26. How Can B Get the Secret? <ul><li>He can convince the system he’s A </li></ul><ul><li>– A problem for authentication </li></ul><ul><li>He can break into A’s memory </li></ul><ul><li>– That doesn’t use message IPC </li></ul><ul><li>– And is handled by page tables </li></ul><ul><li>He can forge a message from someone else to get the secret </li></ul><ul><li>He can “eavesdrop” on someone else who gets the secret </li></ul>
  27. 27. Forging An Identity
  28. 28. Operating System Protections <ul><li>The operating system knows who each process belongs to </li></ul><ul><li>It can tag the message with the identity of the sender </li></ul><ul><li>If the receiver cares, he can know the identity </li></ul>
  29. 29. How About Eavesdropping?
  30. 30. What’s Really Going on Here? <ul><li>On a single machine, what is a message send, really? </li></ul><ul><li>A message is copied from a process buffer to an OS buffer </li></ul><ul><li>– Then from the OS buffer to another process’ buffer </li></ul><ul><li>• If attacker can’t get at processes’ internal buffers and can’t get at OS buffers, he can’t “eavesdrop” </li></ul>
  31. 31. File Protection <ul><li>How do we apply these access protection mechanisms to a real system resource? </li></ul><ul><li>Files are a common example of a typically shared resource </li></ul><ul><li>If an OS supports multiple users, it needs to address the question of file protection </li></ul>
  32. 32. Unix File Protection <ul><li>A model for protecting files developed in the 1970s </li></ul><ul><li>Still in very wide use today </li></ul><ul><li>– With relatively few modifications </li></ul><ul><li>But not very flexible </li></ul>
  33. 33. Unix File Protection Philosophy <ul><li>Essentially, Unix uses a limited ACL </li></ul><ul><li>Only three subjects per file </li></ul><ul><li>– Owner </li></ul><ul><li>– Group </li></ul><ul><li>– Other </li></ul><ul><li>Limited set of rights specifiable </li></ul><ul><li>– Read, write, execute </li></ul><ul><li>– Special meanings for some file types </li></ul>
  34. 34. Unix Groups <ul><li>A set of Unix users can be joined into a group </li></ul><ul><li>All users in that group receive common privileges </li></ul><ul><li>– Except file owners always get the owner privileges </li></ul><ul><li>A user can be in multiple groups </li></ul><ul><li>But a file has only one group </li></ul>
  35. 35. Setuid and Setgid <ul><li>Unix mechanisms for changing your user identity and group identity </li></ul><ul><li>Either indefinitely or for the run of a single program </li></ul><ul><li>Created to deal with inflexibilities of the Unix access control model </li></ul><ul><li>But the source of endless security problems </li></ul>
  36. 36. Unix File Access Control and Complete Mediation <ul><li>Unix doesn’t offer complete mediation </li></ul><ul><li>File access is checked on open to a file </li></ul><ul><li>– For the requested modes of access </li></ul><ul><li>Opening program can use the file in the open mode for as long as it wants </li></ul><ul><li>– Even if the file’s access permissions change </li></ul><ul><li>Substantially cheaper in performance </li></ul>
  37. 37. Pros and Cons of Unix File Protection Model <ul><li>+ Low cost </li></ul><ul><li>+ Simple and easy to understand </li></ul><ul><li>+ Time tested </li></ul><ul><li>– Lacking in flexibility </li></ul><ul><li>• In granularity of control </li></ul><ul><li>– Subject and object </li></ul><ul><li>• In what controls are possible </li></ul><ul><li>– No complete mediation </li></ul>
  38. 38. Other OS Security Functions <ul><li>OS must enforce access control </li></ul><ul><li>Authentication </li></ul><ul><ul><li>Passwords, biometrics </li></ul></ul><ul><ul><li>Single sign-on, etc. </li></ul></ul><ul><li>Authorization </li></ul><ul><ul><li>ACL </li></ul></ul><ul><ul><li>Capabilities </li></ul></ul><ul><li>OS is an attractive target for attack! </li></ul>
  39. 39. Desired Security Features of a Normal OS <ul><li>Authentication of users </li></ul><ul><li>Memory protection </li></ul><ul><li>File and I/O access control </li></ul><ul><li>General object access control </li></ul><ul><li>Enforcement of sharing </li></ul><ul><li>Fairness guarantees </li></ul><ul><li>Secure IPC and synchronization </li></ul><ul><li>Security of OS protection mechanisms </li></ul>
  40. 40. Extra Features for a Trusted OS <ul><li>Mandatory and discretionary access control </li></ul><ul><li>Object reuse protection </li></ul><ul><li>Complete mediation </li></ul><ul><li>Audit capabilities </li></ul><ul><li>Intruder detection capabilities </li></ul>
  41. 41. Trusted Operating System <ul><li>An OS is trusted if we rely on it for </li></ul><ul><ul><li>Memory protection </li></ul></ul><ul><ul><li>File protection </li></ul></ul><ul><ul><li>Authentication </li></ul></ul><ul><ul><li>Authorization </li></ul></ul><ul><li>Every OS does these things </li></ul><ul><li>But if a trusted OS fails to provide these, our security fails </li></ul>
  42. 42. Trust vs Security <ul><li>Security is a judgment of effectiveness </li></ul><ul><li>Judged based on specified policy </li></ul><ul><li>Security depends on trust relationships </li></ul><ul><li>Trust implies reliance </li></ul><ul><li>Trust is binary </li></ul><ul><li>Ideally, only trust secure systems </li></ul><ul><li>All trust relationships should be explicit </li></ul>
  43. 43. Trusted Operating Systems <ul><li>Trust implies reliance </li></ul><ul><li>A trusted system is relied on for security </li></ul><ul><li>An untrusted system is not relied on for security </li></ul><ul><li>If all untrusted systems are compromised, your security is unaffected </li></ul><ul><li>Ironically, only a trusted system can break your security! </li></ul>
  44. 44. Trusted OS <ul><li>OS mediates interactions between subjects (users) and objects (resources) </li></ul><ul><li>Trusted OS must decide </li></ul><ul><ul><li>Which objects to protect and how </li></ul></ul><ul><ul><li>Which subjects are allowed to do what </li></ul></ul>
  45. 45. General Security Principles <ul><li>Least privilege  like “low watermark” </li></ul><ul><li>Simplicity </li></ul><ul><li>Open design (Kerchoffs Principle) </li></ul><ul><li>Complete mediation </li></ul><ul><li>White listing (preferable to black listing) </li></ul><ul><li>Separation </li></ul><ul><li>Ease of use </li></ul><ul><li>But commercial OSs emphasize features </li></ul><ul><ul><li>Results in complexity and poor security </li></ul></ul>
  46. 46. MAC and DAC <ul><li>Mandatory Access Control (MAC) </li></ul><ul><ul><li>Access not controlled by owner of object </li></ul></ul><ul><ul><li>Example: User does not decide who holds a TOP SECRET clearance </li></ul></ul><ul><li>Discretionary Access Control (DAC) </li></ul><ul><ul><li>Owner of object determines access </li></ul></ul><ul><ul><li>Example: UNIX/Windows file protection </li></ul></ul><ul><li>If DAC and MAC both apply, MAC wins </li></ul>
  47. 47. Object Reuse Protection <ul><li>OS must prevent leaking of info </li></ul><ul><li>Example </li></ul><ul><ul><li>User creates a file </li></ul></ul><ul><ul><li>Space allocated on disk </li></ul></ul><ul><ul><li>But same space previously used </li></ul></ul><ul><ul><li>“ Leftover” bits could leak information </li></ul></ul><ul><ul><li>Magnetic remanence is a related issue </li></ul></ul>
  48. 48. How To Achieve OS Security <ul><li>Kernelized design </li></ul><ul><li>Separation and isolation mechanisms </li></ul><ul><li>Virtualization </li></ul><ul><li>Layered design </li></ul>
  49. 49. Advantages of Kernelization <ul><li>Smaller amount of trusted code </li></ul><ul><li>Easier to check every access </li></ul><ul><li>Separation from other complex pieces of the system </li></ul><ul><li>Easier to maintain and modify security features </li></ul>
  50. 50. Security Kernel <ul><li>Kernel is the lowest-level part of the OS </li></ul><ul><li>Kernel is responsible for </li></ul><ul><ul><li>Synchronization </li></ul></ul><ul><ul><li>Inter-process communication </li></ul></ul><ul><ul><li>Message passing </li></ul></ul><ul><ul><li>Interrupt handling </li></ul></ul><ul><li>The security kernel is the part of the kernel that deals with security </li></ul><ul><li>Security kernel contained within the kernel </li></ul>
  51. 51. Security Kernel <ul><li>Why have a security kernel? </li></ul><ul><li>All accesses go thru kernel </li></ul><ul><ul><li>Ideal place for access control </li></ul></ul><ul><li>Security-critical functions in one location </li></ul><ul><ul><li>Easier to analyze and test </li></ul></ul><ul><ul><li>Easier to modify </li></ul></ul><ul><li>More difficult for attacker to get in “below” security functions </li></ul>
  52. 52. Reference Monitor <ul><li>An important security concept for OS design </li></ul><ul><li>A reference monitor is a subsystem that controls access to objects </li></ul><ul><li>– It provides (potentially) complete mediation </li></ul><ul><li>Must be tamper-resistant </li></ul><ul><li>Must be analyzable </li></ul><ul><ul><li>Small </li></ul></ul><ul><ul><li>Simple, etc. </li></ul></ul>
  53. 53. Trusted Computing Base <ul><li>TCB  everything in the OS that we rely on to enforce security </li></ul><ul><li>If everything outside TCB is subverted, trusted OS would still be trusted </li></ul><ul><li>TCB protects users from each other </li></ul><ul><ul><li>Context switching between users </li></ul></ul><ul><ul><li>Shared processes </li></ul></ul><ul><ul><li>Memory protection for users </li></ul></ul><ul><ul><li>I/O operations, etc. </li></ul></ul>
  54. 54. TCB Implementation <ul><li>Security may occur many places within OS </li></ul><ul><li>Ideally, design security kernel first, and build the OS around it </li></ul><ul><ul><li>Reality is usually the other way around </li></ul></ul><ul><li>Example of a trusted OS: SCOMP </li></ul><ul><ul><li>Developed by Honeywell </li></ul></ul><ul><ul><li>Less than 10,000 LOC in SCOMP security kernel </li></ul></ul><ul><ul><li>Win XP has 40,000,000 lines of code! </li></ul></ul>
  55. 55. TCB Design Hardware Security kernel Operating system User space Security kernel is the security layer
  56. 56. Assurance of Trusted Operating Systems <ul><li>How do I know that I should trust someone’s operating system? </li></ul><ul><li>What methods can I use to achieve the level of trust I require? </li></ul>
  57. 57. Assurance Methods <ul><li>Testing </li></ul><ul><li>Formal verification </li></ul><ul><li>Validation </li></ul>
  58. 58. Secure Operating System Standards <ul><li>If I want to buy a secure operating system, how do I compare options? </li></ul><ul><li>Use established standards for OS security </li></ul><ul><li>Several standards exist </li></ul>
  59. 59. Some Security Standards <ul><li>U.S. Orange Book </li></ul><ul><li>European ITSEC </li></ul><ul><li>U.S. Combined Federal Criteria </li></ul><ul><li>Common Criteria for Information Technology Security Evaluation </li></ul>
  60. 60. The U.S. Orange Book <ul><li>The earliest evaluation standard for trusted operating systems </li></ul><ul><li>Defined by the Department of Defense in the late 1970s </li></ul><ul><li>Now largely a historical artifact </li></ul>
  61. 61. Purpose of the Orange Book <ul><li>To set standards by which OS security could be evaluated </li></ul><ul><li>Fairly strong definitions of what features and capabilities an OS had to have to achieve certain levels </li></ul><ul><li>Allowing “head-to-head” evaluation of security of systems </li></ul><ul><li>– And specification of requirements </li></ul>
  62. 62. The Common Criteria <ul><li>Modern international standards for computer systems security </li></ul><ul><li>Covers more than just operating systems </li></ul><ul><li>Design based on lessons learned from earlier security standards </li></ul><ul><li>Lengthy documents describe the Common Criteria </li></ul>
  63. 63. Basics of Common Criteria Approach <ul><li>Highly detailed methodology for specifying </li></ul><ul><li>1. What security goals a system has </li></ul><ul><li>2. What environment it operates in </li></ul><ul><li>3. What mechanisms it uses to </li></ul><ul><li>achieve its security goals </li></ul><ul><li>4. Why anyone should believe it does so </li></ul>
  64. 64. Logging and Auditing <ul><li>An important part of a complete security solution </li></ul><ul><li>Practical security depends on knowing what is happening in your system </li></ul><ul><li>Logging and auditing is required for that purpose </li></ul>
  65. 65. Logging <ul><li>No security system will stop all attacks </li></ul><ul><li>– Logging what has happened is vital </li></ul><ul><li>to dealing with the holes </li></ul><ul><li>Logging also tells you when someone is trying to break in </li></ul><ul><li>– Perhaps giving you a chance to close </li></ul><ul><li>possible holes </li></ul>
  66. 66. Auditing <ul><li>Security mechanisms are great </li></ul><ul><li>– If you have proper policies to use them </li></ul><ul><li>Security policies are great </li></ul><ul><li>– If you follow them </li></ul><ul><li>For practical systems, proper policies and consistent use are a major security problem </li></ul>
  67. 67. Auditing <ul><li>A formal (or semi-formal) process of verifying system security </li></ul><ul><li>A requirement if you really want your systems to run securely </li></ul><ul><li>Auditing should be done </li></ul><ul><li>– Periodically </li></ul><ul><li>– After making major system changes </li></ul><ul><li>– When problems arise </li></ul>
  68. 68. What Does an Audit Cover? <ul><li>Conformance to policy </li></ul><ul><li>Review of control structures </li></ul><ul><li>Examination of audit trail (logs) </li></ul><ul><li>User awareness of security </li></ul><ul><li>Physical controls </li></ul><ul><li>Software licensing and intellectual property issues </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.