Your SlideShare is downloading. ×
OS Security 2009
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

OS Security 2009


Published on

OS Security 2009

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


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