Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Lecture 20 Overview 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 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 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 OS Functions 5 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 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 Trusted OS Functions 8 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) Kernel • OS part that performs lowest level functions User tasks OS OS Kernel Hardware 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 Security Kernel • Modifiability – security mechanism changes are easier to make and test • Compactness – relatively small • Verifiability – formal methods , all situations are covered Lecture 21 Trusted Operating System CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Hesham El-Rewini Reference Monitor • portion of a security kernel that controls accesses to objects • Collection of access controls for – Devices, Files, Memory, Interprocess communication, Other objects Gate • It must be O O O S S S – Always invoked when any object is accessed – Small enough • analysis, testing – Tamperproof 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 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 TCB and Non-TCB Code Applications Utilities Non-TCB User request interpreter … Segmentation, paging, memory management Primitive I/O Basic Operations Clocks, timing Interrupt handling Hardware:registers memory Capabilities TCB TCB monitors basic interactions • Process activation • Execution domain switching • Memory Protection • I/O operation 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 Separate Security Kernel Security Kernel: -Access control -Authentication functions User tasks OS Security Kernel Hardware OS: - Resource allocation - Sharing - Hardware interactions Separation • Physical Separation • Temporal Separation • Cryptographic Separation • Logical separation (isolation) 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 Virtual machine Virtual Machine Virtual Machine Virtual Machine User 1 User 2 User 3 Real OS Real System Resources Layered OS User processes Compilers, database OS Utility functions File system, device allocation Scheduling, sharing, MM Synchronization, allocation Security kernel Security functions Hardware OS kernel Modules operating in Different Layers Least trusted code Most trusted code Data update Data comparison User ID lookup User Authentication module User interface 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 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 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 Example: find minimum Entry min A[1] i1 ii+1 yes Exit i>n no yes min < A[i] no min A[i] Finding the minimum value Assertions P: n > 0 Q: R: n > 0 and S: 1 i n and for all j 1 j i -1 min A[j] n > 0 and 1 i n and min A[1] n > 0 and i = n + 1 and for all j 1 j i -1 min A[j] Validation • Requirements checking – system does things it should do • also, system does not do things it is not supposed to do • Design and code reviews – traceability from each requirement to design and code components • System testing – data expected from reading the requirement document can be confirmed in the actual running of the system Security Policies 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 Military Security policy Unclassified Restricted Confidential Secret Top Secret Access to Information • Information access is limited by the need-toknow rule • Compartment: Each piece of classified information may be associated with one or more projects called compartments Compartments and Sensitivity Levels Compartment 1 Top Secret Secret Compartment 3 Confidential Restricted Unclassified Compartment 2 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 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. 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}> 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 Lattice Upper bound Lower bound 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) 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). Illustration o5 s2 High o4 o3 s1 o1 o2 Low Harrison, Ruzzo, and Ullman Model S1 S1 S2 S3 S2 S3 O1 control O2 O3 Owner read control control Owner Read write read Owner execute read read execute 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 Take Grant Model • Unlimited number of subjects and objects • States and state transitions • Directed graph • Four primitive operations: – take – create – grant – revoke Take Grant Model (Cont.) S2 O2 read execute read S1 Read, write O1 O3 read execute S3 Create S S O becomes rights Revoke S S O O becomes r1, r2, r3 r1, r2 Take S1 S2 take O read becomes read S1 S2 take read O Grant read S1 S2 O grant becomes read S1 S2 grant read O