Introduction Operating System Security, Designing trusted - PDF document

Introduction Operating System Security, • Designing trusted operating systems Continued • Encapsulated environments CS 239 Security for Networks and System Software May 22, 2002 Lecture 14 Lecture 14 Page 1 Page 2 CS 239, Spring 2002 CS 239, Spring 2002 Designing Trusted Operating Security Policies and Trusted Systems Operating Systems • Security professionals tend to speak of trust , • A policy is a statement of the security rather than security, in this context we expect the system to enforce • A more practical definition of what OS • We trust a system to the degree we users want believe it properly implements its • The user’s trust that the OS will provide policy certain security features properly Lecture 14 Lecture 14 Page 3 Page 4 CS 239, Spring 2002 CS 239, Spring 2002 Discretionary and Mandatory More on Mandatory Access Access Control Control • Discretionary access control means • Allows higher authorities to control that the users can choose to enforce it what users do with data they can –Or not access • Mandatory access control means the • Can prevent a user from telling a secret system forces access control on the to someone who “shouldn’t” know it users –Whether they like it or not Lecture 14 Lecture 14 Page 5 Page 6 CS 239, Spring 2002 CS 239, Spring 2002 1

Why Would We Want To Returning to Our Example Prevent It? Process A Process B • What if the secret is proprietary Gimme your information? secret • What if the secret is essentially access to valuable software? • What if we’re concerned that B will be able to fool A? What if the system authorities don’t want A – Perhaps via social engineering? to tell the secret to B? • What if A and B are processes, not people? Can we prevent this? Lecture 14 Lecture 14 Page 7 Page 8 CS 239, Spring 2002 CS 239, Spring 2002 Common Security Policies Military Security Policies • Based on several ranks of security • Designed to state what we do and don’t – Unclassified want to allow – Restricted –Like the previous example – Confidential • Military security policies – Secret – Top secret • Commercial security policies • And compartmentalized by the need to know Lecture 14 Lecture 14 Page 9 Page 10 CS 239, Spring 2002 CS 239, Spring 2002 Determining Security Access in Clearances in Military Security Military Models • A clearance describes what • Based on a dominance relationship information a subject can know • A subject dominates an object iff: • All information has some security label – the subject has a more restricted • A subject can access information only rank than the object and if he has the proper clearance –the subject has access to the all the • A combination of the rank and the compartments of the object compartment allowed Lecture 14 Lecture 14 Page 11 Page 12 CS 239, Spring 2002 CS 239, Spring 2002 2

Commercial Security Policies Clark-Wilson Security Policy • Typically less rigid and hierarchical • Particularly concerned with data integrity than military policies • System designer specifies well-formed • But with similar concerns transactions • Generally more flexibility in setting up • System must guarantee that all levels and compartments permitted operations conform to such • And in assigning access privileges transactions Lecture 14 Lecture 14 Page 13 Page 14 CS 239, Spring 2002 CS 239, Spring 2002 Separation of Duty Security Chinese Wall Security Policy Policy • Meant to provide strict separation between • To guarantee that important parts of a company commercial activities are not – For intellectual property reasons performed improperly by employees – Or to prevent conflicts of interest • Requires active participation by • Defines classes of conflicts among different multiple parties to achieve a goal groups in the company –Even if one or more parties is • Subjects cannot access information from permitted to perform every step more than one class member Lecture 14 Lecture 14 Page 15 Page 16 CS 239, Spring 2002 CS 239, Spring 2002 Models of Security Lattice Model of Security • A generalization of military model • Lattice model • Elements of the lattice are the security • Bell-La Padua model labels of the subjects and objects • Many other models exist • A partial ordering is defined on the lattice –Some are practical elements –Some are useful for proving • Access is permitted from one element to another if first is “greater” than the second theoretical limits of security Lecture 14 Lecture 14 Page 17 Page 18 CS 239, Spring 2002 CS 239, Spring 2002 3

Bell-La Padua Confidentiality Example of the Lattice Model Model • Describes allowable paths of •E can access A, G but A can’t access information flow in a secure system E F E •A and B cannot • Another formalization of military A B C D access each other security model •Everyone can access J H • Designed for systems that handle data •G can access J at multiple levels of sensitivity everyone Lecture 14 Lecture 14 Page 19 Page 20 CS 239, Spring 2002 CS 239, Spring 2002 Important Security Properties for Simple Security Property Bell-LaPadua • Simple security property • Subject s may have read access to object o only if C(o) <= C(s) • *-Property • Means that I can read any object if I Means that I can read any object if I • Tranquility property have a higher enough security class have a higher enough security class • So the general can listen to what the So the general can listen to what the private says private says Lecture 14 Lecture 14 Page 21 Page 22 CS 239, Spring 2002 CS 239, Spring 2002 *-Property Tranquility Property • Subject s who has read access to object o • Classification of a subject or object can may have write access to object p only if change C(o) <= C(p) –But not while the subject is • Means that I can only write to objects at my security class or higher accessing anything • Means the general can’t say anything to the –Or while the object is being accessed private • Thereby assuring complete mediation • Prevents write-down Lecture 14 Lecture 14 Page 23 Page 24 CS 239, Spring 2002 CS 239, Spring 2002 4

Thinking About This Security Desired Security Features of a Model Normal OS • Authentication of users • Let’s say I want it in my operating • Memory protection system • File and I/O access control • How do I get it? • General object access control • Enforcement of sharing • What are the implications of having it? • Fairness guarantees • Secure IPC and synchronization • Security of OS protection mechanisms Lecture 14 Lecture 14 Page 25 Page 26 CS 239, Spring 2002 CS 239, Spring 2002 Extra Features for a Trusted OS How To Achieve OS Security • Mandatory and discretionary access • Kernelized design control • Separation and isolation mechanisms • Object reuse protection • Virtualization • Complete mediation • Layered design • Audit capabilities • Intruder detection capabilities Lecture 14 Lecture 14 Page 27 Page 28 CS 239, Spring 2002 CS 239, Spring 2002 Advantages of Kernelization Reference Monitors • An important security concept for OS • Smaller amount of trusted code design • Easier to check every access • A reference monitor is a subsystem • Separation from other complex pieces that controls access to objects of the system –It provides (potentially) complete • Easier to maintain and modify security mediation features • Very important to get this part right Lecture 14 Lecture 14 Page 29 Page 30 CS 239, Spring 2002 CS 239, Spring 2002 5

Assurance of Trusted Operating Assurance Methods Systems • How do I know that I should trust • Testing someone’s operating system? • Formal verification • What methods can I use to achieve the • Validation level of trust I require? Lecture 14 Lecture 14 Page 31 Page 32 CS 239, Spring 2002 CS 239, Spring 2002 Secure Operating System Some Security Standards Standards • If I want to buy a secure operating • U.S. Orange Book system, how do I compare options? • European ITSEC • Use established standards for OS • U.S. Combined Federal Criteria security • Common Criteria for Information • Several standards exist Technology Security Evaluation Lecture 14 Lecture 14 Page 33 Page 34 CS 239, Spring 2002 CS 239, Spring 2002 The U.S. Orange Book Purpose of the Orange Book • To set standards by which OS security • The earliest evaluation standard for could be evaluated trusted operating systems • Fairly strong definitions of what features • Defined by the Department of Defense and capabilities an OS had to have to in the late 1970s achieve certain levels • Allowing “head-to-head” evaluation of • Now largely a historical artifact security of systems – And specification of requirements Lecture 14 Lecture 14 Page 35 Page 36 CS 239, Spring 2002 CS 239, Spring 2002 6