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

1,459
views

Published on

OS Security 2009

OS Security 2009

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,459
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
60
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×