1 / 61

Lecture 2

Lecture 2. Access Control. Contents. Identification and Authentication Basic Principles and Concepts of Access Control Identity-Based Access Control Access Operations UNIX Access Control ACL and Access Matrix Role-based Access Control New Challenges. Identification & Authentication.

ciaran-downs
Download Presentation

Lecture 2

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. Lecture 2 Access Control

  2. Contents • Identification and Authentication • Basic Principles and Concepts of Access Control • Identity-Based Access Control • Access Operations • UNIX Access Control • ACL and Access Matrix • Role-based Access Control • New Challenges

  3. Identification & Authentication • A secure system has to track the identities of the users requesting its services • The user identity is a parameter in access control decisions; • The user identity is recorded when logging security-relevant events in an audit trail. • Identification: Announce who you are. • Authentication: You prove that you are who you claim to be.

  4. Password • Threats for Identification • Password guessing • Password spoofing • Compromise of the password file. • To avoid attacks such as • Exhaustive search • Intelligent search • Defense: • Set a password • Change default password • Password length • Password format • Avoid obvious passwords

  5. System help • Password checkers • Password generation • Password ageing • Limit login attempts • Inform users

  6. Spoofing Attacks • Who gets the user name and password? • Displaying the number of failed logins • Trusted path: e.g., NT’s CNTL+ALT+DEL • Mutual authentication: The system should be required to authenticate itself to the user.

  7. Protecting the Password file • Cryptographic protection • Access Control enforced by the OS • Combination

  8.  Intel Password Rules • In order to protect your security, Intel has certain rules for choosing passwords. Please read the following rules so that you will know how to choose a good password. • The following rules apply to all passwords: • The password must be at least 8 characters long. • The password must contain at least: • one alpha character [a-zA-Z]; • one numeric character [0-9]; • one special character from this set: • ` ! @ $ % ^ & * ( ) - _ = + [ ] ; : ' " , < . > / ? • The password must not: • contain spaces; • begin with an exclamation [!] or a question mark [?]; • contain your login ID. • The first 3 characters cannot be the same. • The sequence of the first 3 characters cannot be in your login ID. • The first 8 characters cannot be the same as in your previous password. • Passwords are treated as case sensitive.

  9. Examples • Invalid or poorly chosen passwords: • Your login ID. • Names of co-workers, pets, family, etc. • Phone numbers, license numbers, or birthdays. • Simple passwords like "asdf" (adjacent keys on a keyboard). • Words, which can be found in a dictionary. • Strong passwords (the following are for example purposes only; do not use any of these examples as your actual password): • Use a name, modified slightly, like "b0b$mith" or "M@ryL0ng". • Use a phrase you can remember, like "hello world" modified to "hel10@World". • "tL*5i?wu" (contains letters, special characters, and numbers).

  10. Alternatives • Something you know • PIN • Something you hold • Smart card • Who you are • Palm prints, finger prints, iris pattern, retina pattern • What you do • Signature: form, speed, pressure, • Where you are • Which terminal, which client, registered position

  11. What is access control? • A generic term for the process by which a computer system controls the interaction between users and system resources • To implement a security policy, which may be determined by • organisational requirements • statutory requirements (medical records, for example) • Policy requirements may include • confidentiality (restrictions on read access) • integrity (restrictions on write access) • availability

  12. A schematic view • A user requests access (read, write, print, etc.) to a resource in the computer system • The reference monitor • establishes the validity of the request … • … and returns a decision either granting or denying access to the user Access Request Reference Monitor System Decision

  13. Simple analogies • Consider a paper-based office in which certain documents should only be read by certain individuals • We could implement security by • storing documents in filing cabinets • issuing keys to the relevant individuals for the appropriate cabinets • The reference monitor is the set of (locked) filing cabinets • An access request (an attempt to open a filing cabinet) is granted if the key fits the lock (and denied otherwise)

  14. Simple analogies • Consider now a night club where only certain individuals are allowed into the club • We can implement security by • employing a bouncer • providing the bouncer with a guest list (that is, a list of people permitted to enter the club) • The reference monitor is the security guard + the guest list • An access request is granted only if • a club-goer can prove their identity (authentication) • she is on the guest list

  15. Subjects and objects • Subject • Active entity in a computer system • User, process, thread • We will assume that a subject is synonymous with a user • Object • Passive entity or resource in a computer system • Files, directories, printers

  16. Authentication & authorization • If s is a statement, authentication answers the question ‘Who said s?’ with a subject. Subjects make statements; this is what they are for. • If o is an object, authorization answers the question ‘Who is trusted to access o?’ with a subject. • Often access rules are attached to objects as an access control list (ACL): for each operation, the ACL specifies a set of authorized subjects

  17. Fact file • Model assumes identity-based access control: ACL entries are ‘human readable’ subjects; it may seem that access control by definition requires that identities (of persons) are verified • Access rules are local: we do not have to search for the rule that is applicable, it is stored as an ACL with the object • Enforcement of rules is centralized: the reference monitor does not consult other parties when making a decision • Simple access operations: read, write, execute

  18. Identity-based access control • The kind of access control we are used to form operating systems like Unix or Windows • Appropriate for ‘closed’ systems where one can physically find the users • Do not confuse the ‘identity’ of a person with a ‘user identity (uid)’ in an operating systems; a uid is just a unique identifier that need not correspond to a real person (e.g. ‘root’)

  19. Changes of 1990s • On the Internet we can deal with parties we never met before. Their ‘identity’ can hardly figure in our access rules. • Access is controlled at the level of applets, not at the granularity of read/write/execute • Access control is a two-stage process: • 1. Decide on the access rule that should be applied; third parties may get involved at this stage • 2. Apply the access rules to individual requests

  20. Changing the focus • User identities link a user’s privileges to a current access request, but there is no necessity to describe or enforce access control by reference to subjects (users) • Instead of asking who made the request, ask what to do with it

  21. Access control without sources • 1. The receiver may associate UID diego with a particular person (optional) • 2. After running a context establishment protocol, the receiver puts UID diego into the security context ‘xxxx’ (similar to session key) • 3. The receiver handles the request within the security context with context identifier ‘xxxx’ • 4. The receiver does not verify the source of the request

  22. Security contexts • Security contexts are collections of access control parameters. They correspond to subjects, but can hardly be described as the sources of access requests. • Authentication answers the question ‘Which security context should be associated with this access request?’. • Authorization evaluates the request within that security context.

  23. Trust management • A unified approach to specifying and interpreting security policies, credentials, and relationships. • Generalize rules: instead of ACLs, use a programming language to express assertions • Distribute authority: assertions can be local (‘policies’) or be signed by another authority (‘credentials’)

  24. Trust management • Credentials can directly authorize actions, there is no need to authenticate a user • Trust management engine (compliance checker) answers question ‘Does the set C of credentials prove that the request r complies with the local security policy P?’ • Challenge: How to find a set of credentials that satisfies a given policy • Trade-off between the expressiveness of the language and the complexity of the compliance checker • Trust management systems do not manage trust

  25. Code-based access control • Evidence used in access decisions can be site of code origin: local or remote? • URL of code origin: intranet or Internet? • code signature: signed by trusted author? • code identity: approved (‘trusted’) code? • code proof: code author provides proof of security properties • Found in Java security and in .NET security

  26. Call chains • A has access right to resource R, B does not; A calls B and B requests access to R: should access be granted? • A conservative answer is ‘no’, but A could explicitly delegate the access right to B • A has access right to resource R, B does not; B calls A and A requests access to R: should access be granted? • A conservative answer is ‘no’, but A could explicitly assert its access right

  27. Delegation • Alice ‘delegates’ to Bob the right to use one of her resources: put this access right into an ACL • It depends on policy whether Bob can delegate this right to another user; Alice can manage her own ACL • Alice ‘delegates her identity (uid)’ to a process (subject) running in a computer system • It depends on policy whether the process can delegate her uid to other processes, but usually it is not an option to ask Alice

  28. Access operations • An interaction between an object and a subject • A subject may observe (read) an object • Information flows from object to subject • A subject may alter (write to) an object • Information flows from subject to object

  29. Back to the analogies • In the club example • a subject is a club-goer • the only objects are the club and the guest list • access operations could include “enter club” and “delete guest” (that is, change the guest list) • In the filing cabinet example • a subject is a user of the files in the cabinets • an object is a filing cabinet or a file in one of the cabinets • access operations could include read and write (for files) and also “remove key from user”

  30. Read and write access • In a multi-user OS users open files to get access • Files are opened for read or for write access so that the OS can avoid conflicts like two users simultaneously writing to the same file • Write access mode is usually implemented as read/write mode • A user editing a file should not be asked to open it twice • The append (or “blind write” or write-only) access mode allows users to alter an object without observing its contents • Rarely useful (audit log files being the main exception) • Implemented in Multics

  31. The execute access operation • Sometimes an object can be used without opening it in read or write mode • Directories • Binary executable files • Cryptographic keys • We include the execute access operation • This may mean different things in different contexts and in different systems

  32. UNIX access operations • File access • Read (r) • Write (w) • Execute (x) • Directory access • Read (list directory contents) • Write (create or rename files in directory) • Execute (search directory)

  33. UNIX ls command

  34. The UNIX reference monitor • Users have an ID and a group ID • 12.6 represents a user with group ID 12 and user ID 6 (within that group) • Objects have an ID (determined by the creator of the object) and a group ID (determined by the group ID of the creator) • 12.6 is the object ID of an object created by user 12.6 • Objects also have an access mask • A pattern of 9 bits in 3 groups of 3

  35. The UNIX reference monitor • The access mask of the Research directory is 101 101 111 representing x-r x-r xwr • The ls output reverses the order of the bits • Assume the ID of the Research directory is 12.6 • Any user has the default access given by the first 3 bits (read and execute in this case) • Any user with ID 12.x has group access because the user ID and object ID match in the first place • The user with ID 12.6 has owner access because the user ID and object ID match in both places

  36. The access control matrix • Introduced by Lampson (1972) and extended by Harrison, Ruzzo and Ullman (1976-8) • Columns indexed by objects • Rows indexed by subjects • Matrix entries are (sets of) access operations • Foundation of many theoretical security models Objects Subjects

  37. The access control matrix • A request can be regarded as a triple (s,o,a) • s is a subject • o is an object • a is an access operation • A request is granted (by the reference monitor) if • a belongs to the access matrix entry corresponding to subject s and object o

  38. The access control matrix • The request (jason, allfiles.txt, w) is granted • The request (mick, allfiles.txt, w) is denied Objects Subjects

  39. Disadvantages • Abstract formulation of access control not suitable for direct implementation • The matrix is likely to be extremely sparse and therefore implementation is inefficient • Management of the matrix is likely to be extremely difficult if there are XXXXs of files and XXs of users (resulting in XXXXXXs of matrix entries)

  40. Access control lists • An ACL corresponds to a column in the access control matrix • [a.out: (jason, {r,w,x}), (mick, {r,x})] • How would a reference monitor that uses ACLs check the validity of the request (jason, a.out, r)? Objects Subjects

  41. Access control lists • Access control lists focus on the objects • Typically implemented at operating system level • WindowsNT uses ACLs • Disadvantage • How can we check the access rights of a particular subject efficiently (“before-the-act per-subject review”)?

  42. Capability lists • A capability list corresponds to a row in the access control matrix • [jason: (trash, {r,w}), (a.out, {r,w,x}), (allfiles.txt, {r,w})] • How would such a reference monitor check the validity of the request (jason, a.out, r)? Objects Subjects

  43. Capability lists • Capability lists focus on the subjects • Typically implemented in services and application software • Database applications often use capability lists to implement fine-grained access to tables and queries • Renewed interest in capability-based access control for distributed systems • Disadvantage • How can we check which subjects can access a given object (“before-the-act per-object review”)?

  44. Back to the analogies • An ACL is analogous to a guest list • the club is the object • the favoured clubbers appear on the list • A capability list is analogous to the set of keys issued to a user (the subject) for unlocking the filing cabinets (the objects)

  45. Administration • Tasks include • Creation of new objects and subjects • Deletion of objects and subjects • Changing entries in access control matrix (changing entries in ACLs and capability lists) • The administration of access control structures is extremely time-consuming, complicated and error-prone

  46. Aggregation • There are several important theoretical results (Harrison, Ruzzo and Ullman; Lipton and Snyder) that demonstrate that it is extremely difficult to anticipate the consequences of administrative actions • Access control structures that aggregate subjects and objects are used to simplify the administrative burden

  47. Aggregation techniques • User groups • Roles • Procedures • Data types

  48. Groups • Access rights are often defined for groups of users • In UNIX three groups are associated with each object • Owner • Group (owner) • Others • In VMS there are four groups • Owner • Group • World • System • In VSTa, a complicated hierarchical group structures can be constructed based on the UNIX model (Andrew Valenciahttp://www.vsta.org:8080/)

  49. Roles • A data type is a set of objects with the same structure (bank accounts, for example) • We define access operations (procedures or permissions) on a data type • Permissions are assigned to roles • Users are assigned to roles • A role is a collection of application-specific operations (procedures) • Roles are (usually) arranged in a hierarchy

More Related