Access Control Models: From the real-world to trusted computing potx

Access Control Models: From the real-world to trusted computing Lecture Motivation  We have looked at protocols for distributing and establishing keys used for authentication and confidentiality  But who should you give these keys to? Who should you trust? What are the rules governing when to and not to give out security credentials  In this lecture, we will look at the broad area of secure and trusted systems – We will focus on access control models – These methods are often used to abstract the requirements for a computer system – But, they hold for general systems where security is a concern (e.g networks, computers, companies…) Lecture Outline  Some generic discussion about security  Objects that require protection  Insights from the real-world  Access control to memory and generic objects – Discretionary Methods: Directory Lists, Access Control Lists, and the Access Control Matrix, Take-Grant Model – Failures of DACs: Trojan Horses – Dominance and information flow, Multilevel security and lattices – Bell-LaPadula and Biba’s Model  What is a trusted system? Trusted Computing Base System-security vs Message-security  In the cryptographic formulation of security, we were concerned with the confidentiality, authenticity, integrity, and non-repudiation of messages being exchanged – This is a message-level view of security  A system-level view of security has slightly different issues that need to be considered – Confidentiality: Concealment of information or resources from those without the right or privilege to observe this information – Integrity: Trustworthiness of data (has an object been changed in an unauthorized manner?) – Availability: Is the system and its resources available for usage? Confidentiality in Systems  Many of the motivations behind confidentiality comes from the military’s notion of restricting access to information based on clearance levels and need-to-know  Cryptography supports confidentiality: The scrambling of data makes it incomprehensible – Cryptographic keys control access to the data, but the keys themselves become an object that must be protected  System-dependent mechanisms can prevent processes from illicitly accessing information – Example: Owner, group, and public concepts in Unix’s r/w/x definition of access control  Resource-hiding: – Often revealing what the configuration of a system is (e.g use of a Windows web server), is a desirable form of confidentiality Integrity in Systems  Integrity includes: – Data integrity (is the content unmodified?) – Origin integrity (is the source of the data really what is claimed, aka Authentication)  Two classes of integrity mechanisms: Prevention and Detection  Prevention: Seek to block unauthorized attempts to change the data, or attempts to change data in unauthorized ways – A user should not be able to change data he is not authorized to change – A user with privileges to work with or alter the data should not be allowed to change data in ways not authorized by the system – The first type is addressed through authentication and access control – The second type is much harder and requires policies  Detection: Seek to report that data’s integrity has been violated – Achieved by analyzing the system’s events (system logs), or analyze data to see if required constraints are violated Availability of Systems  Availability is concerned with system reliability – The security side of the issue: An adversary may try to make a resource or service unavailable – Implications often take the form: Eve compromises a secondary system and then denies service to the primary system… as a result all requests of the first system get redirected to second system – Hence, when used in concert with other methods, the effects can be very devastating  Denial of service attacks are an example: – Preventing the server from having the resources needed to perform its function – Prevent the destination from receiving messages – Denial of service is not necessary deliberate Threats  There are several threats that may seek to undermine confidentiality, integrity, and availability: – Disclosure Threats: Causing unauthorized access to information – Deception Threats: Causing acceptance of false data – Disruption Threats: Prevention of correct operation of a service – Usurpation Threats: Unauthorized control of some service  Examples: – Snooping: Unauthorized interception of information (passive Disclosure) – Modification/Alteration: Unauthorized change of information (active Deception, Disruption, Usurpation) – Masquerading/Spoofing: Impersonation of one entity by another (Deception and Disruption) – Repudiation of Origin: False denial that an entity sent or created data (Deception) – Denial of Receipt: A false denial that an entity received some information or message (Deception) – Delay: A temporary delay in the delivery of a service (Usurpation) – Denial of Service: A long-term inhibition of service (Usurpation) Overview Security Policies  Definition: A security policy is a statement of what is allowed and what is not allowed to occur between entities in a system  Definition: A security mechanism is a method for enforcing a security policy  Policies may be expressed mathematically – Allowed and disallowed states may be specified – Rules may be formulated for which entity is allowed to which action  These policies may seek to accomplish: – Prevention – Detection – Recovery  This lecture will focus primarily on formal statements of security policies – Specifically, we will focus on policies associated with access control and information flow Objects that Need Protection  Modern operating systems follow a multiprogramming model: – Resources on a single computer system (extend this to a generic system) could be shared and accessed by multiple users – Key technologies: Scheduling, sharing, parallelism – Monitors oversee each process/program’s execution  Challenge of the multiprogramming environment: Now there are more entities to deal with… hard to keep every process/user happy when sharing resources… Even harder if one user is malicious Several objects that need protection: – Memory – File or data on an auxiliary storage device – Executing program in memory – Directory of files – Hardware Devices – Data structures and Tables in operating systems – Passwords and user authentication mechanisms – Protection mechanisms  Take-Grant Models, pg  Since the graph only includes arcs corresponding to non-empty entries in the access control matrix, the model provides a compact representation  Question of Take-Grant Models: Can an initial protection graph and rules be manipulated to produce a particular access right for A to access C with?  Example: X A A creates V with {t,g} X t A B {t,g} t B C V C A t B X X A takes X to C from V A {t,g} V t B g C X V C C B grants to V the X to C X t A B g V B takes g to V from A X t A B {t,g} g X X X C Problems with Discretionary Access Control  Discretionary access controls are inadequate for enforcing information flow policies – They provide no constraint on copying information from one object to another  Example: Consider Alice, Bob, and Eve Alice has a file X that she wants Bob to read, but not Eve – Alice authorizes Bob via the following Access Control Matrix   File X File Y Alice Own   Bob Read Write Eve   Read – Bob can subvert Alice’s discretion by copying X into Y Bob has write privileges, and Eve has read privileges for Y – This case is a simplistic version of what can be much more pathological… The Trojan Horse… DAC and Trojan Horses    What if Bob isn’t bad… Eve could still read X by convincing Bob to use a program carrying a Trojan Horse (Troy) Consider the new access control matrix: – Eve has created Troy and given it to Bob, who has execute privileges – Troy inherits Bob’s read privileges to X, and write privileges to a file Y (perhaps public) – Eve has read privileges to file Y Trojan Horses perform normal “claimed” operations, but also participates in subversive activities   File X File Y Prog. Troy Alice Own     Bob Read Write Execute Eve   Read Read,  Write,  Execute Prog. Troy Read Write   Solution: Impose Mandatory Access Controls (MAC… yes, another MAC!) that cannot be bypassed Dominance and Information Flow  There are two basic ways to look at the notion of security privileges: Dominance and Information Flow  For all essential purposes, they are the same, and its just a matter of semantics  Let’s start with dominance: – Each piece of information is ranked at a particular sensitivity level (e.g unclassified, confidential, secret, top secret) – The ranks form a hierarchy, information at one level is less sensitive than information at a higher level – Hence, higher level information dominates lower level information  Formally, we define a dominance relation ≤ on the set of objects and subjects if: s ≤ o ⇔ (rank s ≤ rank o ) ∧ ( comps ⊆ compo )  We say that o dominates s (or s is dominated by o) if s ≤ o Dominance and Information Flow, pg  Now let us look at information flow: – Every object is given a security class (or a security label): Information flowing from objects implies information flowing between the corresponding security classes – We define a can-flow relationship A → B to specify that information is allowed to flow from entities in security class A to entities in security class B – We also define a class-combining operator A ⊕ B = C to specify that objects that contain information from security classes A and B should be labeled with security class C – Implicitly, there is the notion of cannot-flow A NOT → B   Lattice Model of Access Security  The dominance or can-flow relationship defines a partial ordering relationship by which we may specify a lattice (with Denning’s axioms)  First, the dominance relationship is transitive and antisymmetric – Transitive: If a ≤ b and b ≤ c , then a ≤ c – Antisymmetric: If a ≤ b and b ≤ a then a = b  A lattice is a set of elements organized by a partial ordering that satisfies the least upper bound (supremum) and greatest lower bound properties (infimum)  Supremum: Every pair of elements possesses a least upper bound  Infimum: Every pair of elements possesses a greatest lower bound  In addition to supremum and infimum between two objects, we need the entire set of security classes to have a supremum and infimum (i.e single low point and single high point) Examples of Information Flow and Lattices  High-Low Policy: Two security classes (high and low)  Bounded Isolated Classes: A set of classes Aj Between any two security classes define the composition A j ⊕ A k = H Every class has the low class as its infimum  Subset Lattice: Categories A, B, C may be combined to form compartments List of all subsets forms a lattice H {A,B,C} H {A,B} L A1 {B,C} {A} … {A,C} {B} {C} An L {} Mandatory Access Control (MAC) Models  Mandatory Access Control (MAC): When a system mechanism controls access to an object and an individual user cannot alter that access, the control is mandatory access control  In MAC, typically requires a central authority – E.g the operating system enforces the control by checking information associated with both the subject and the object to determine whether the subject should access the object  MAC is suitable for military scenarios: – An individual data owner does not decide who has top-secret clearance – The data owner cannot change the classification of an object from top secret to a lower level – On military systems, the reference monitor must enforce that objects from one security level cannot be copied into objects of another level, or into a different compartment!  Example MAC model: Bell-LaPadula Bell-LaPadula Model  The Bell-LaPadula model describes the allowable flows of information in a secure system, and is a formalization of the military security policy  One motivation: Allow for concurrent computation on data at two different security levels – One machine should be able to be used for top-secret and confidential data at the same time – Programs processing top-secret data would be prevented from leaking top-secret data to confidential data, and confidential users would be prevented from accessing top-secret data  The key idea in BLP is to augment DAC with MAC to enforce information flow policies – In addition to an access control matrix, BLP also includes the military security levels – Each subject has a clearance, and each object has a classification – Authorization in the DAC is not sufficient, a subject must also be authorized in the MAC Bell-LaPadula Model, pg  Formally, BLP involves a set of subjects S and a set of objects O – Each subject s and object o have fixed security classes λ(s) and λ(o) – Tranquility Principle: Subjects and objects cannot change their security levels once they have been instantiated  There are two principles that characterize the secure flow of information: Simple-Security Property: A subject s may have read access to an object o if and only if λ(o) ≤ λ(s) *-Property: A subject s can write to object o iff  Read access implies a flow from object to subject  λ(s) ≤ λ (o) λ( o ) → λ( s ) Write access implies a flow from subject to object λ( s ) → λ( o ) Bell-LaPadula Model, pg  –  Humans are trusted not to leak information –  High Security Level The *-property is not applied to users: Programs are assumed untrustworthy… could be Trojan Horses The *-property prohibits a program running at the secret level from writing to unclassified documents Sometimes *-property is modified to require λ(s)=λ(o) in order to prevent “write-up” problems O3 w S r O2 r O1 Low Security Level BLP and Trojan Horses  Return to the Trojan Horse problem: – Alice and Bob are secret level users, Eve is an unclassified user – Alice and Bob can have both secret and unclassified subjects (programs) – Eve can only have unclassified subjects – Alice creates secret file X – Simple security prevents Eve from reading X directly – Bob can either have a secret (S-Troy) or an unclassified (U-Troy) TrojanHorse carrying program – S-Troy: Bob running S-Troy will create Y, which will be a secret file Eve’s unclassified subjects will not be able to read Y – U-Troy: Bob running U-Troy won’t be able to read X, and so won’t be able to copy it into Y  Thus BLP prevents flow between security classes  One problem remains: Covert Channels… but that’s for another lecture… From BLP to Biba  BLP was concerned with confidentiality– keeping data inaccessible to those without proper access privileges  The Biba model is the integrity counterpart to BLP – Low-integrity information should not be allowed to flow to high-integrity objects – High-integrity is placed at the top of the lattice and low integrity at the bottom Information flows from top to bottom (opposite direction of BLP)  Biba’s model principles Simple-Integrity Property: Subject s can read object o iff ω(s) ≤ ω(o) Integrity *-Property: Subject s can write object o only if ω(o) ≤ ω(s)  In this sense, Biba is the dual of BLP and there is very little difference between Biba and BLP: – Both are concerned with information flow in a lattice of security classes Trusted (Operating) System Design  Operating systems control the interaction between subjects and objects, and mechanisms to enforce this control should be planned for at the design phase of the system  Some design principles: – Least Privilege: Each user and program should operate with the fewest privileges possible (minimizes damage from inadvertent or malicious misuse) – Open Design: The protection mechanisms should be publicly known so as to provide public scrutiny – Multiple Levels of Protection: Access to objects should depend on more than one condition (e.g password and token) – Minimize Shared Resources: Shared resources provide (covert) means for information flow Trusted (Operating) System Design, pg  Unlike a typical OS, a Trusted OS involves each object being protected by an access control mechanism – Users must pass through an access control layer to use the OS – Another access control layer separates the OS from using program libraries  A trusted OS includes: – User identification and authentication – MAC and DAC – Object reuse protection: When subjects finish using objects, the resources may be released for use by other subjects Must be careful! Sanitize the object! – Audit mechanisms: Maintain a log of events that have transpired Efficient use of audit resources is a major problem! – Intrusion detection: Detection mechanisms that allow for the identification of security violations or infiltrations  Trusted Computing Base (TCB): everything in the trusted operating system that enforces a security policy ... Mandatory Access Control (MAC) Models  Mandatory Access Control (MAC): When a system mechanism controls access to an object and an individual user cannot alter that access, the control is mandatory... protection  Insights from the real-world  Access control to memory and generic objects – Discretionary Methods: Directory Lists, Access Control Lists, and the Access Control Matrix, Take-Grant... should not be allowed to flow to high-integrity objects – High-integrity is placed at the top of the lattice and low integrity at the bottom Information flows from top to bottom (opposite direction