Trusted Operating Systems contd CSCI 283 Fall 2003

Trusted Operating Systems – contd. CSCI 283 Fall 2003 Lecture 8 GWU Draws extensively from Memon’s notes, Brooklyn Poly And text, Chapter 5 YOU ARE EXPECTED TO READ CHAPTER 5 FROM THE TEXT IN ADDITION TO THIS CS 283/Fall 03/GWU/Vora/Lecture 9

Announcements http: //www. cacr. math. uwaterloo. ca/hac/ Handbook of Applied Crypto; free online book – really great reference on all crypto algorithms Graduate Events (undergrads very welcome too) http: //www. cs. gwu. edu/~studentcorner/graduate. Event s/ – Fri. , 7 th Nov. , 2 -3: 30, Graduate Seminar Exam: 6: 30 -8: 30, Wed. , 17 th Dec. , this classroom 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 2

Announcements Regional ACM Programming Contest info http: //www. acm. seas. gwu. edu/icpc/ 12: 30 pm - 5: 30 pm, Saturday, Nov. 8. Marvin Center 307 Spectators welcome/solicited 4 Web Cameras with live feeds; Camera URL: http: //www. acm. seas. gwu. edu/icpc/cameras/ 15 teams competing at GW, another 142 other teams at other sites Competing simultaneously. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 3

Clark-Wilson Integrity Model • In commercial environment we worry about the integrity of the data in the system and the actions performed upon that data. • The data is said to be in a consistent state (or consistent) if it satisfies given properties. – For example, let D be the amount of money deposited so far today, W the amount of money withdrawn so far today, YB be the amount of money in all accounts at the end of yesterday, and TB be the amount of money in all accounts so far today. Then the consistency property is: D + YB – W = TB 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 4

CW Model • A well-formed transaction is a series of operations that leave the data in a consistent state if the data is in a consistent state when the transaction begins. • The principle of separation of duty requires the certifier and the implementers be different people. – In order for the transaction to corrupt the data (either by illicitly changing data or by leaving the data in an inconsistent state), either two different people must make similar mistakes or collude to certify the well-formed transaction as correct. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 5

CW Model • The Clark-Wilson Model defines data subject to its integrity controls as constrained data items or CDIs. • Data not subject to the integrity controls are called uncon-strained data items, or UDIs. • Integrity verification procedures, or IVPs, test that the CDIs conform to the integrity constraints at the time the IVPs are run. In this case, the system is said to be in a valid state. • Transformation procedures, or TPs, change the state of the data in the system from one valid state to another; TPs implement well-formed transactions. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 6

CW Model • Certification Rule 1 (CR 1): When any IVP is run, it must ensure that all CDIs are in a valid state. • Certification Rule 2 (CR 2): For some associated set of CDIs, a TP must transform those CDIs in a valid state into a (possibly different) valid state. – CR 2 defines a certified relation C that associates a set of CDIs with a particular TP; • Enforcement Rule 1 (ER 1): The system must maintain the certified relations, and must ensure that only TPs certified to run on a CDI manipulate that CDI. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 7

CW Model • Enforcement Rule 2 (ER 2): The system must associate a user with each TP and set of CDIs. The TP may access those CDIs on behalf of the associated user. If the user is not associated with a particular TP and CDI, then the TP cannot access that CDI on behalf of that user. – This defines a set of triple (user, TP, { CDI set }) to capture the association of users, TPs, and CDIs. Call this relation allowed A. Of course, these relations must be certified: 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 8

CW Model • Enforcement Rule 3 (ER 3): The system must authenticate each user attempting to execute a TP. • Enforcement Rule 4 (ER 4): Only the certifier of a TP may change the list of entities associated with that TP. No certifier of a TP, or of an entity associated with that TP, may ever have execute permission with respect to that entity. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 9

Examples Using the following partial orders, define lattices Subset of ? Divisor of ? Less than equal to ? – lower bound? 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 10

Lattice - Example G E A What can I remove so this is not a lattice? F B D C H 1/11/2022 J CS 283/Fall 03/GWU/Vora/Lecture 9 11

BLP – Simple Version The secure flow of information is characterized by: – Simple Security Property: A subject s may have read access to an object o if and only if o s – *-Property: A subject s who has read access to an object o may have write access to an object p only if o p (Contents of a sensitive object can only be written to objects at least as high. That is, prevent writedown). 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 12

Biba Integrity Model The properties of the Biba Integrity Model are: – Simple Integrity Property: Subject s can modify (have write access to) object o if and only if I(s) >= I(o). – Integrity *-property: If subject S has read access to object o with integrity level I(o), S can have write access to p if and only if I(o) >= I(p). 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 13

Exercise Write a set of rules combining the secrecy controls of BLP with the integrity controls of Biba 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 14

Denning’s requirements • Information should be able to flow freely among members of a single class – reflexivity. • Information flow should be transitive. • BLP exhibits both characteristics. • However, information flow policies are more general and need not be transitive and even if they are may not be modeled by a lattice. • These are rules, need them to be consistent. Show that BLP exhibits both characteristics 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 15

Confinement Flow Models • Each entity, a, is assigned a confinement pair – confine(a) = (a. L a. U) where a. L is the lowest classification of information allowed to flow out of a and a. U is the highest classification of information allowed to flow into a. • Example: Confine(x) = [Confidential, Confidential] Confine(y) = [Secret, Secret] Confine(z) = [Confidential, Topsecret] Possible flows? Secure or allowed flows? Transitive? Graph 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 16

Compiler-Based Mechanisms • Need some language construct to relate variables to security classes. Example: x: integer class { A B } may mean that security classes A and B may flow into x. • Assignment statements: x : = y + z; for this to be a secure flow lub{y, z} <= x. Draw representative graph 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 17

Compiler-Based Mechanisms • Conditional Statements: if x + y < z then a : = b else d : = b * c – x; Requirement for secure flow is 1. b <= a; 2. lub {b, c, x} <= d 3. lub {x, y, z } <= gub { a, d } Draw graph 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 18

Execution Based Mechanisms • Consider if x == 1 then y : = a else y : = b; Information flows from x and a or x and b to y. But if a <= y only if some other variable z is 1 then compiler has no way of checking this. Need run time mechanisms. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 19

You need to know • How to tell if X can access Y from a graph • How to tell if something dominates something else, in integrity or confidentiality • How to tell if a graph is a lattice • How to construct a lattice given an example • How to determine secure flows from a piece of pseudo-code or a graph. • How to tell if a graph is consistent with a given model/pseudo-code 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 20

Need • Policy: description of requirements • Model: policy representation: check if policy can be enforced • Design: implementation of policy • Trust: based on features and assurance 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 21

Harrison-Ruzzo-Ullman (HRU) Model Can be used to answer questions like: • Can user X ever have access to object Y? Commands that consist of conditions and primitive operations 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 22

HRU - command name(o 1, o 2, o 3, … on) if r 1 in A[s 1, o 1] and r 2 in A[s 2, o 2] and … rm in A[sm, om] then op 1 op 2 … opk end 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 23

HRU - Primitive operations, op • • • create subject s create object o destroy subject s destroy object o enter right r into A[s, o] delete right r from A[s, o] Operations are enough to model, for example, the Unix protection mechanism 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 24

Can show that In the HRU modelled system, • If commands are restricted to one operation each, it is possible to decide whether a given subject can ever obtain a particular right to an object • If commands are not restricted to one operation each, it is not always decidable whether a given protection system can confer a given right 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 25

Take-Grant system Primitive operations: create, revoke, take, grant Can we decide if a given object can share an object with another subject? Yes. Can we decide if a given subject can steal access to an object from another subject? Yes. Proofs use representation of properties as graphs 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 26

Operations represented as graphs S S 1/11/2022 Create Object q r O r S Revoke Right CS 283/Fall 03/GWU/Vora/Lecture 9 S O q O 27

More operations as graphs r Grant S r P O S Grant O r P r S Take 1/11/2022 O r P S CS 283/Fall 03/GWU/Vora/Lecture 9 Take P O 28

Need • Policy: description of requirements • Model: policy representation: check if policy can be enforced • Design: implementation of policy • Trust: based on features and assurance 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 29

Design Principles for Secure Systems • Two basic themes: – Simplicity – KISS • Makes design and interactions easy • Easy to prove its safety – Restriction • Minimize the power of entities • Compartmentalization • Common Sense! 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 30

Principles of design 1. 2. 3. 4. 5. 6. 7. 8. Principle of least privilege Principle of fail-safe defaults Principle of economy of mechanism Principle of complete mediation Principle of open design Principle of separation of privilege Principle of least common mechanism Principle of psychological acceptability 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 31

Principle of least privilege Entity should be given only those privilege needed to finish a task – Function/role should control the rights – Temporary elevation of privilege should be relinquished immediately – Granularity of privileges 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 32

Principle of fail-safe defaults Unless a subject is given explicit access to an object, it should be denied access to the object. – Default access to an object is none – If subject is unable to complete its task before it terminates it should undo changes made to the state of the system. – Restricting privileges at the time of creation 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 33

Principle of economy of mechanism Security mechanism should be as simple as possible. – Fewer errors – Testing and verification is easy – Assumptions are less 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 34

Principle of complete mediation All accesses to objects should be checked to ensure they are allowed. Illegitimate access attempts should be expected and protected against – Security vs. performance issues 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 35

Principle of open design Security of a mechanism should not depend upon secrecy of its design or implementation – Secrecy != security – Complexity != security – “Security through obscurity” – Cryptography and openness – AES 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 36

Principle of separation of privilege System should not grant permission based on single condition – Company checks over $75, 000 to be signed by two officers. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 37

Principle of least common mechanism Mechanisms used to access resources should not be shared – Why? 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 38

Principle of psychological acceptability • Security mechanism should not make the resource difficult to access • Recognizes the most important element in computer security? Human 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 39

Design Principles for Privacy • Fair information practices - US Privacy Act of 1974. • Openness and transparency: No secret record keeping. This includes both the publication of existence, as well as contents. • Individual participation: The subject of a record should be able to see and correct the record. • Collection limitation: Data collection should be proportional to the purpose of the collection. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 40

Design Principles for Privacy -2 • Data quality: Data should be relevant to the purposes for which they are collected and should be kept up to date. • Use limitation: Data should only be used for their specific purpose by authorized personnel. • Reasonable security: Adequate security safeguards should be put in place, according to the sensitivity of the data collected. • Accountability: Record keepers must be accountable for compliance with the other principles. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 41

Need • Policy: description of requirements • Model: policy representation: check if policy can be enforced • Design: implementation of policy • Trust: based on features and assurance 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 42

Trusted OS Features • • • ID and Authentication Mandatory and Discretionary Access Control Object Reuse Protection Complete Mediation Trusted Path (makes Trojan Horse intercepting data/man in the middle more difficult) • Accountability and Audit Log • Audit Log Reduction – issues: too much, too little, how to make sense? • Intrusion Detection – statistical analysis of logs 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 43

Security Kernel Enforces security mechanisms of entire OS; provides security interfaces among h/w, OS, other parts Covers all object access Can isolate security mechanisms Compactness – sometimes Modularity: change, test etc. Can be verified, analyzed through forma methods, etc. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 44

Parts of the security kernel • Reference Monitor: controls access. Needs to be small and tamperproof. Part of TCB. • Trusted Computing Base (TCB): everything necessary to enforce security policy. • TCB constituted of: – – 1/11/2022 h/w processes and interprocess communication primitive files protected memory CS 283/Fall 03/GWU/Vora/Lecture 9 45

Parts of TCB • TCB constituted of: – – h/w processes and interprocess communication primitive files protected memory • Not in TCB: user apps, user environment, directories, procedures, memory management 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 46

TCB function • Process Activation – Requires complete change of registers, file access lists, process status info. • Execution domain switch when processes in one domain invoke processes in other domains • Memory Protection • I/O 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 47

HW Read up on Microsoft’s Trusted Windows plan, once known as Palladium. Critique it. Find Bill Arbaugh’s comments on TCPA. Do not turn in, I will ask questions in class. 1/11/2022 CS 283/Fall 03/GWU/Vora/Lecture 9 48