* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Designing Trusted Operating Systems Operating Systems
Post-quantum cryptography wikipedia , lookup
Airport security wikipedia , lookup
Wireless security wikipedia , lookup
Distributed firewall wikipedia , lookup
Information security wikipedia , lookup
Access control wikipedia , lookup
Multilevel security wikipedia , lookup
Cyber-security regulation wikipedia , lookup
Mobile security wikipedia , lookup
Cybercrime countermeasures wikipedia , lookup
Trusted Computing wikipedia , lookup
Unix security wikipedia , lookup
Computer security wikipedia , lookup
Chapter 5 – Designing Trusted Operating Systems What makes an operating system “secure”? Or “trustworthy? How are trusted systems designed, and which of those design principles carry over naturally to other program development tasks? How do we develop “assurance” of the correctness of a trusted operating systems? Designing Trusted Operating Systems Primitive security services • Memory protection • File protection • General object access control • User authentication OS is trusted if we have confidence that it provides these four services in a consistent and effective way. What is a trusted system? Secure Trusted Either-or: something either is or is not secure Graded: There are degrees of “trustworthiness Property of presenter Property of receiver Asserted based on product characteristics Judged based on evidence and analysis Absolute: not qualified as Relative: viewed in to how, where, when, or context of use by whom used A goal A characteristic What is a trusted system? Trusted process – process that can affect system security Trusted product – evaluated and approved product Trusted software- software portion of system that can be relied upon to enforce security policy Trusted computing base – set of all protection mechanisms within a computing system that enforce a nified security policy Trusted system – system that employs sufficient hardware and software integrity measures to allow its use for processing sensitive information Security Policies security policy – statement of security we expect the system to enforce Military Security Policy • based on protecting classified information • Information access is limited by needto-know rule • Each piece of classified info is associated with a compartment Military Security Policy Class (classification) - <rank; compartment> Clearance - indication that person is trusted to access info up to a certain level of sensitivity Dominance – s <= O iff ranks <= ranko and compartmentss <= compartmentso Clearance level of subject is at least as high as that of the information Subject has a need to know about all compartments for which the information is classified. Commercial Security Policies Data items at any level may have different degrees of sensitivity (public, proprietary, internal) No formalized notion of clearances No dominance function for most commercial information access Clark-Wilson Commercial Security Policy Well-formed transactions – perform steps in order, exactly as listed & authenticating the individuals who perform the steps Goal – maintain consistency between internal data and external expectations of the data Process constrained data items by transformation procedures • <userID, TPi, {CDIj, CDIk, …}> Commercial Security Policy Separation of duty – division of responsibilities (manual system) Chinese Wall Security Policy – • Confidentiality Policy • Objects (e.g. files) • Company Groups (all objects concerning a particular company) • Conflict classes (cluster competing companies) 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 its requirements Multilevel Security Want to build a model to represent a range of sensitivities and to reflect need to separate subjects from objects to which they should not have access. Use the lattice model of security • military security model where <= in the model is the relation operator in the lattice (transitive, antisymmetric) • Commercial security model (public, proprietary, internal) Bell-La Padula Confidentiality Model Formal description of allowable paths of information flow in a secure system • Simple Security Property. A subject s may have read access to an object o only if C(o) <= C(s) • *-Property – 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) The *-property is used to prevent write-down (subject with access to high-level data transfers that data by writing it to a low-level object. Bibb Integrity Model Simple Integrity Property. Subject s can modify (have write access to) object o 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 object p only if I(o) >= I(p) Models Proving Theoretical Limitations of Security Systems Graham-Denning Model – introduced concept of a formal system of protection rules; constructs a model having generic protection properties Harrison-Ruzzo-Ullman Model – uses commands involving conditions and primitive operations where a protection system is a set of subjects, objects, rights, and commands Take-Grant Systems Four operations performed by subjects on objects with rights • Create(o,r) subject creates an object with certain rights • Revoke(o,r) subject removes rights from object • Grant(o,p,r) subject grants to o access rights on p • Take (o,p,r) subject removes from o access rights on p Trusted System Design Elements Least privilege Economy of mechanism Open design Complete mediation Permission based Separation of privilege Least common mechanism Ease of use Security Features of Ordinary Operating Systems Authentication of users Protection of memory File and I/O device access control Allocation and access control to general objects Enforcement of sharing Guarantee of fair service Interprocess communications and synchronization Protection of operating system protection data Security Features of Trusted Operating Systems Trusted systems incorporate technology to address both features and assurance Objects are accompanied (surrounded) by an access control mechanism Memory is separated by user, and data and program libraries have controlled sharing and separation Security Features of Trusted Operating Systems Identification and Authentication • Require secure id of individuals, each individual must be uniquely identified Mandatory and Discretionary Access Control • MAC – access control policy decisions are made beyond the control of the individual owner of the object • DAC – leaves access control to the discretion of the object’s owner • MAC has precedence over DAC Security Features of Trusted Operating Systems Object Reuse Protection • Prevent object reuse leakage • OS clears (overwrites) all space to be reassigned • Problem of magnetic remanence Complete Mediation • All accesses must be controled Trusted Path • For critical operations (setting password, etc.), users want unmistakable communications Security Features of Trusted Operating Systems Accountability and Audit • Maintain a log of security relevant events • Audit log must be protected from outsiders Audit Log Reduction • Audit only open and close of files/objects Intrusion detection • Build patterns of normal system usage, triggering an alarm any time usage seems abnormal • Intrusion prevention Kernelized Design Kernel – part of OS that performs lowest-level functions • Synchronization, interprocess communications, message passing, interrupt handling • Security kernel – responsible for enforcing security mechanism for entire OS; provides interface among the hardware, OS, and other parts of computer system