1 / 35

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

Explore access control models and their use in secure and trusted systems, including discussions on confidentiality, integrity, and availability. Learn about threats to security and methods to prevent unauthorized access and data modification.

demarco
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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…)

  3. 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

  4. 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?

  5. 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

  6. 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

  7. 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

  8. 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)

  9. 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 do 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

  10. 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

  11. Basic Strategies for Protection • There are a few basic mechanisms at work in the operating system that provide protection: • Physical separation: processes use different physical objects (different printers for different levels of users) • Temporal separation: Processes having different security requirements are executed at different time • Logical separation: Operating system constrains a program’s accesses so that it can’t access objects outside its permitted domain • Cryptographic separation: Processes conceal their data in such a way that they are unintelligible to outside processes • Share via access limitation: Operating system determines whether a user can have access to an object • Limit types of use of an object: Operating system determines what operations a user might perform on an object • When thinking of access to an object, we should consider its granularity: • Larger objects are easier to control, but sometimes pieces of large objects don’t need protection. • Maybe break objects into smaller objects (see Landwehr)

  12. Access Control to Memory • Memory access protection is one of the most basic functionalities of a multiprogramming OS • Memory protection is fairly simple because memory access must go through certain points in the hardware • Fence registers, Base/Bound registers • Tagged architectures: Every word of machine memory has one or more extra bits to identify access rights to that word (these bits are set only by privileged OS operations) • Segmentation: Programs and data are broken into segments. The OS maintains a table of segment names and their true addresses. The OS may check each request for memory access when it conducts table lookup. • More general objects may be accessed from a broader variety of entry points and there may be many levels of privileges: • No central authority!

  13. Insight from Real-world Security Models • Not all information is equally sensitive– some data will have more drastic consequences if leaked than other. • Military sensitivity levels: unclassified, confidential, secret, top secret • Generally, fewer people knowing a secret makes it easier to control dissemination of that information • Military notion of need-to-know: Classified information should not be entrusted to an individual unless he has both the clearance level and the need to know that information • Compartments: Breaking information into specific topical areas (compartments) and using that as a component in deciding access • Security levels consist of sensitivity levels and the corresponding compartments • If information is designated to belong to multiple compartments, then the individual must be cleared for all compartments before he can access the information.

  14. Real-world Security Models, pg. 2 • Documents may be viewed as a collection of sub-objects, some of which are more sensitive than others. • Hence, objects may be multilevel in their security context. • Level of classification of an object or document is usually the classification of its most sensitive information it contains. • Aggregation Problem: Often times the combination of two pieces of data creates a new object that is more sensitive than either of the pieces separately • Sanitization Problem: Documents may have sensitive information removed in an effort to sanitize the document. It is a challenge to determine when enough information has been removed to densensitize a document.

  15. Multilevel Security Models • We want models that represent a range of sensitivities and that separate subjects from the objects they should not have access to. • The military has developed various models for securing information • We will look at several models for multilevel security • Object-by-Object Methods: Directory lists, Access control lists, Access control matrix, Take-Grant Model • Lattice model: A generalized model • Bell-LaPadula Model • Biba Model

  16. Access Control to Objects • Some terminology: • Protection system: The component of the system architecture whose task is to protect and enforce security policies • Object: An object is an entity that is to be protected (e.g. a file, or a process) • Subject: Set of active objects (such as processes and users) that have interaction with other • Rights: The rules and relationships allowed to exist between subjects and objects • Directory-based Access Control (aka. Capability List): A list for each subject which specifies which objects that subject can access (and what rights) • Access Control List: A list for each object that specifies which subjects can access it (and how).

  17. Access Control Matrix • Access control matrix arose in both OS research and database research • Example: • What does it mean for a process to read/write/execute another process? • Read is to receive signals from, write is to send signals to, and execute is to run as a subprocess • Formally, an access control matrix is a table in which each row represents a subject and each column represents an object. • Each entry in the table specifies the set of access rights for that subject to that object • In general access control matrices are sparse: most subjects to not have access rights to most objects • Every subject is also an object!!!

  18. Access Control Matrix, pg. 2 • All accesses to objects by subjects are mediated by an enforcement mechanism that uses the access matrix • This enforcement mechanism is the reference monitor. • Some operations allow for modification of the matrix (e.g. owner might be allowed to grant permission to another user to read a file) • Owner has complete discretion to change the access rules of an object it owns (discretionary access control) • The access control matrix is a generic way of specifying rules, and is not beholden to any specific access rules • It is therefore very flexible and suitable to a broad variety of scenarios • However, it is difficult to prove assertions about the protection provided by systems following an access control matrix without looking at the specific meanings of subjects, objects, and rules • Not suitable for specialized requirements, like the military access control model.

  19. r, g r, w Take-Grant Models Take Operation: • Take-Grant Models represent a system using a directed graph • Nodes in the graph are either subjects or objects • An arc directed from node A to node B indicates that the subject/object A has some access rights to subject or object B. • Access rights are: read (r), write (w), take (t), grant (g) • Take implies that node A can take node B’s access rights to any other node • Grant implies that node B can be given any access right A possesses r, g t A B C Grant Operation: g A B r, w C

  20. X={r,g} X={r,g} X\Y={r} B B B Take-Grant Models, pg. 2 Create Operation: • Create Rule: A subject A can create a new graph G1 from an old graph G0 by adding a vertex B and an edge from A to B with rights set X. • Remove Rule: Let A and B be distinct vertices. Suppose there is an edge with rights X. Rules Y may be removed from X to produce X\Y. If X\Y is empty, the edge is deleted. A Delete Operation: A A

  21. Take-Grant Models, pg. 3 • 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 B with? • Example: X X X t t A B C A B C 1. A creates V with {t,g} 3. B grants to V the X to C X t X t A B C A B C {t,g} g X V V X 2. B takes g to V from A 4. A takes X to C from V X t X t A B C A B C {t,g} g {t,g} g X V V

  22. Problems with Discretionary Access Control • Discretionary access controls are inadequate for enforcing information flow policies • The 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 • 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…

  23. 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 Solution: Impose Mandatory Access Controls (MAC… yes, another MAC!) that cannot be bypassed.

  24. 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: • We say that o dominates s (or s is dominated by o) if .

  25. Dominance and Information Flow, pg. 2 • 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 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 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

  26. 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 and , then • Antisymmetric: If and then . • 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)

  27. Examples of Information Flow and Lattices • Bounded Isolated Classes: A set of classes Aj. Between any two security classes define the composition . 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 • High-Low Policy: Two security classes (high and low) H {A,B,C} H {A,B} {A,C} {B,C} A1 An … L {A} {B} {C} L {}

  28. Mandatory Access Control (MAC) Models • Mandatory Access Control (MAC): When a system mechanism controls access to an object and an individual user cannot alter hat 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

  29. 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

  30. Bell-LaPadula Model, pg. 2 • Formally, BLP involves a set of subjects S and a set of objects O. • Each subject s and object o have fixed security classes l(s) and l(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 . • *-Property: A subject s can write to object o iff • Read access implies a flow from object to subject • Write access implies a flow from subject to object

  31. Bell-LaPadula Model, pg. 3 High Security Level • The *-property is not applied to users: • Humans are trusted not to leak information • 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 l(s)=l(o) in order to prevent “write-up” problems O3 w O2 S r r O1 Low Security Level

  32. 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) Trojan-Horse 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…

  33. 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 • Integrity *-Property: Subject s can write object o only if • 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

  34. 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.

  35. Trusted (Operating) System Design, pg. 2 • Unlike a typical OS, a Trusted OS involves each object being protected by an access control mechanism • Users are 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

More Related