1 / 52

Lecture 21 Trusted Operating Systems

Lecture 21 Trusted Operating Systems. CS 450/650 Fundamentals of Integrated Computer Security. Slides are modified from Hesham El-Rewini. What is a Trusted System?. Functional correctness Enforcement of integrity Limited privilege Appropriate confidence level. Security Policy.

tamira
Download Presentation

Lecture 21 Trusted Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 21Trusted Operating Systems CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Hesham El-Rewini

  2. What is a Trusted System? • Functional correctness • Enforcement of integrity • Limited privilege • Appropriate confidence level CS 450/650 Fundamentals of Integrated Computer Security

  3. Security Policy • A security policy is a statement of the security we expect the system to enforce • A system can be trusted only in relation to its security policy • that is, to the security needs the system is expected to satisfy CS 450/650 Lecture 21: Trusted Operating System

  4. Military Security policy Unclassified Restricted Confidential Secret Top Secret CS 450/650 Lecture 21: Trusted Operating System

  5. Access to Information • Information access is limited by the need-to-know rule • Compartment: Each piece of classified information may be associated with one or more projects called compartments CS 450/650 Lecture 21: Trusted Operating System

  6. Compartments and Sensitivity Levels Top Secret Compartment 1 Secret Compartment 2 Confidential Compartment 3 Restricted Unclassified CS 450/650 Lecture 21: Trusted Operating System

  7. Classification & Clearance • <rank; compartments> • class of a piece of information • Clearance: an indication that a person is trusted to access information up to a certain level of sensitivity • <rank; compartments> • clearance of a subject CS 450/650 Lecture 21: Trusted Operating System

  8. Dominance Relation • We say that s dominates o (or o is dominated by s) if o <= s For a subject s and an object o, o <= s if and only if rank(o) <= rank(s) and compartments(o) is subset of compartments(s) • A subject can read an object if the subject dominates the object. CS 450/650 Lecture 21: Trusted Operating System

  9. Example • Information classified as <secret; {Sweden}> • Which of the following subject clearances can read the above information? • <top secret; {Sweden}> • <secret; {Sweden, crypto}> • <top secret; {crypto}> • <confidential; {Sweden}> • <secret; {France}> CS 450/650 Lecture 21: Trusted Operating System

  10. Models of Security • Security models are used to • Test a particular policy for completeness and consistency • Document a policy • Help conceptualize and design an implementation • Check whether an implementation meets the requirements CS 450/650 Lecture 21: Trusted Operating System

  11. Lattice Model Upper bound Lower bound CS 450/650 Lecture 21: Trusted Operating System

  12. Bell-La Padula Model • Formal description of the allowable paths of information flow in a secure system • Set of subjects and another set of objects • Each subject s has a fixed security clearance C(s) • Each object o has a fixed security class C(o) CS 450/650 Lecture 21: Trusted Operating System

  13. Bell-La Padula Model • Two properties characterize the secure flow of information: • A subject s may have read access to an object o only if C(o) <= C(s) • A subject s who has read access to an object o may have write access to an object p only if C(o) <= C(p) • Prevents write-down CS 450/650 Lecture 21: Trusted Operating System

  14. Illustration o5 High Write Read s2 o4 o5 Object Read o3 s2 Subject Write Read s1 o2 Read o1 Low CS 450/650 Lecture 21: Trusted Operating System

  15. Harrison, Ruzzo, and Ullman Model • Command • Conditions and primitive operations CS 450/650 Lecture 21: Trusted Operating System

  16. HRU Model (cont.) • HRU allows state of the protection system to be changed by a well defined set of commands: • Add subject s to M • Add object o to M • Delete subject s from M • Delete object o from M • Add right r to M[s,o] • Delete right r from M[s,o] • Owner can change rights of an object CS 450/650 Lecture 21: Trusted Operating System

  17. Take Grant Model • Unlimited number of subjects and objects • States and state transitions • Directed graph • Four primitive operations: • take • create • grant • revoke CS 450/650 Lecture 21: Trusted Operating System

  18. Take Grant Model (Cont.) S2 read O2 execute Read, write read O1 O3 S1 read execute S3 CS 450/650 Lecture 21: Trusted Operating System

  19. Create S O S becomes rights CS 450/650 Lecture 21: Trusted Operating System

  20. Revoke S O S O becomes r1, r2 r1, r2, r3 CS 450/650 Lecture 21: Trusted Operating System

  21. Take S2 O S1 read take becomes read S2 O S1 read take CS 450/650 Lecture 21: Trusted Operating System

  22. Grant read S2 O S1 grant becomes read S2 O S1 read grant CS 450/650 Lecture 21: Trusted Operating System

  23. CS 450/650 Fundamentals of Integrated Computer Security

  24. Trusted OS Design • OS is a complex system • difficult to design • Adding the responsibility of security enforcement makes it even more difficult • Clear mapping from security requirements to the design • Design must be checked using formal reviews or simulation • Requirements  design  testing CS 450/650 Lecture 21: Trusted Operating System

  25. Security Design Principles • Least privilege • users, programs, fewest privilege possible • Economy of mechanism • small, simple, straight forward • Open design • extensive public scrutiny • Complete mediation • every attempt must be checked CS 450/650 Lecture 21: Trusted Operating System

  26. Security Design Principles • Permission based • denial of access is the default • Separation of privilege • more than one condition • Least common mechanism • the risk of sharing • Ease of use • unlikely to be avoided CS 450/650 Lecture 21: Trusted Operating System

  27. OS Functions CS 450/650 Lecture 21: Trusted Operating System

  28. Security features in ordinary OS • Authentication of users • password comparison • Protection of memory • user space, paging, segmentations • File and I/O device access control • access control matrix • Allocation & access control to general objects • table lookup CS 450/650 Lecture 21: Trusted Operating System

  29. Security features in ordinary OS • Enforcement of sharing • integrity, consistency • Fair service • no starvation • Interprocess communication & synchronization • table lookup • Protection of OS protection data • encryption, hardware control, isolation CS 450/650 Lecture 21: Trusted Operating System

  30. Trusted OS Functions CS 450/650 Lecture 21: Trusted Operating System

  31. Security features of Trusted OS • Identification and Authentication • Mandatory and Discretionary Access Control • Object reuse protection • Complete mediation (all accesses are checked) • Trusted path • Accountability and Audit (security log) • Audit log reduction • Intrusion detection (patterns of normal system usages, anomalies) CS 450/650 Lecture 21: Trusted Operating System

  32. Kernel • OS part that performs lowest level functions User tasks OS OS Kernel Hardware CS 450/650 Lecture 21: Trusted Operating System

  33. Security Kernel • responsible for enforcing security mechanisms of the entire OS • Coverage • ensure that every access is checked • Separation • security mechanisms are isolated from the rest of OS and from user space  easier to protect • Unity • all security mechanisms are performed by a single set of code  easier to trace problems CS 450/650 Lecture 21: Trusted Operating System

  34. Security Kernel • Modifiability • security mechanism changes are easier to make and test • Compactness • relatively small • Verifiability • formal methods , all situations are covered CS 450/650 Lecture 21: Trusted Operating System

  35. Reference Monitor • portion of a security kernel that controls accesses to objects • Collection of access controls for • Devices, Files, Memory, Interprocess communication, Other objects • It must be • Always invoked when any object is accessed • Small enough • analysis, testing • Tamperproof O O O Gate S S S CS 450/650 Lecture 21: Trusted Operating System

  36. Trusted Computing Base (TCB) • Everything in the trusted OS necessary to enforce security policy • System element on which security enforcement depends: • Hardware • processors, memory, registers, and I/O devices • Processes • separate and protect security-critical processes CS 450/650 Lecture 21: Trusted Operating System

  37. Trusted Computing Base (TCB) • System element on which security enforcement depends (cont): • Primitive files • security access control database, identification/authentication data • Protected memory • reference monitor can be protected against tampering • Interprocess communication • e.g., reference monitor can invoke and pass data securely to audit routine CS 450/650 Lecture 21: Trusted Operating System

  38. TCB and Non-TCB Code Applications Utilities User request interpreter … Segmentation, paging, memory management Non-TCB Primitive I/O Basic Operations Clocks, timing Interrupt handling Hardware:registers memory Capabilities TCB CS 450/650 Lecture 21: Trusted Operating System

  39. TCB monitors basic interactions • Process activation • Execution domain switching • Memory Protection • I/O operation CS 450/650 Lecture 21: Trusted Operating System

  40. Combined Security Kernel / OS System OS Kernel: - HW interactions - Access control User tasks OS OS Kernel Hardware OS: • Resource allocation • Sharing • Access control • Authentication functions Security activity CS 450/650 Lecture 21: Trusted Operating System

  41. Separate Security Kernel Security Kernel: • Access control • Authentication functions User tasks OS Security Kernel Hardware OS: • Resource allocation • Sharing • Hardware interactions CS 450/650 Lecture 21: Trusted Operating System

  42. Separation • Physical Separation • Temporal Separation • Cryptographic Separation • Logical separation (isolation) CS 450/650 Lecture 21: Trusted Operating System

  43. Virtualization • OS emulates or simulates a collection of a computer system’s resources • Virtual Machine: Collection of real or simulated hardware facilities • processor, memory, I/O devices CS 450/650 Lecture 21: Trusted Operating System

  44. Virtual machine Virtual Machine User 1 Virtual Machine User 2 Virtual Machine User 3 Real OS Real System Resources CS 450/650 Lecture 21: Trusted Operating System

  45. Layered OS User processes Compilers, database Utility functions OS File system, device allocation Scheduling, sharing, MM Synchronization, allocation OS kernel Security functions Security kernel Hardware CS 450/650 Lecture 21: Trusted Operating System

  46. Modules operating in Different Layers Least trusted code Most trusted code Data update Data comparison User ID lookup User interface User Authentication module CS 450/650 Lecture 21: Trusted Operating System

  47. Assurance • Testing • based on the actual product being evaluated, • not on abstraction • Verification • each of the system’s functions works correctly • Validation • developer is building the right product • according to the specification CS 450/650 Lecture 21: Trusted Operating System

  48. Testing • Observable effects versus internal structure • Can demonstrate existence of a problem, but passing tests does not imply absence of any • Hard to achieve adequate test coverage within reasonable time • inputs & internal states • hard to keep track of all states • Penetrating Testing • tiger team analysis, ethical hacking • Team of experts in design of OS tries to crack system CS 450/650 Lecture 21: Trusted Operating System

  49. Formal verification • The most rigorous method • Rules of mathematical logic to demonstrate that a system has certain security property • Proving a Theorem • Time consuming • Complex process CS 450/650 Lecture 21: Trusted Operating System

  50. Example: find minimum Entry min  A[1] i  1 i  i + 1 yes i > n Exit no yes min < A[i] no min  A[i] CS 450/650 Lecture 21: Trusted Operating System

More Related