EE5552 Network Security and Encryption block 3

1. EE5552 Network Security and Encryptionblock 3 Dr. T.J. Owens Cmath, FIMA, MIEEE Dr T. Itagaki MIET, MIEEE, MAES

2. Block 3 Access Control

3. Objectives (1) • To introduce Access Control • To explain basic concepts of operating system access controls: • Access Control Matrices • Groups and Roles • Access Control Lists • Capabilities • Permission bits

4. Objectives (2) • To provide an overview of operating system vulnerabilities: • Smashing the stack and other technical attacks • User interface failures • Remedies for buffer overflows • To introduce the principle of least privilege

5. Access Control (1) Access control is described by Ross Anderson as the centre of gravity of computer security. It controls which principals can access which system resources, the files they can read, the programs they can execute, with which other principals they can share data, etc. Access control works at a number of levels: • Application • Middleware • Operating system • Hardware

6. Access Control (2) At the application layer a user may see access controls implementing a complex security policy which could assign them many roles. Applications may be written on top of middleware which enforces a number of protection measures. For example, • bookkeeping software may ensure a debit is always matched by a credit. • parental control (lock) on digital TV • Smartcard lock for digital TV’s pay channels

7. Access Control (3) The middleware uses functions provided by the underlying operating system. As this constructs resources such as files from lower level components it acquires responsibility for providing ways to control access to them. The operating system access controls usually rely on hardware features provided by the processor or memory management hardware. • These control the memory addresses a process can access. Moving up from the hardware to the application layer the controls become more complicated and less reliable.

8. Access Control (4) Access control only makes sense in terms of protection goals expressed in a security policy. In the following operating system access control mechanisms are discussed, as their requirements usually drive the design of the hardware protection systems.

9. Operating system access controls (1) The access controls provided with an operating system usually authenticate principals using a mechanism such as passwords or Kerberos and then mediate their access to files, communication ports, and other system resources. The effect of operating system access controls can be modelled by an Access Control Matrix which is a matrix of access permissions with columns for resources and rows for principles.

10. Operating system access controls (2) Let • R denote permission to read • W denote permission to write • E denote permission to execute a program Then the Access Control Matrix lists what users are allowed to do with system resources:

11. Operating system access controls (3) Then the Access Control Matrix lists what users are allowed to do with system resources: • Principals are active parties; they access • Resources are passive; they are accessed • When checking if access is allowed, both principal and resource must be identified • Identities must be unique within their domain

12. Operating system access controls (4) There are three ways to represent an access control matrix: • Access Control Lists • registers per resource what rights the listed principals have to the resource • Capability Lists • registers per principal what rights the principal has to the listed resources • Permission bits - Explained by example later

13. Operating system access controls (5) More formally, • Each row is a process (“subject”) • Each column is a file (“object”) • Each matrix entry is the access rights that subject has for that object

14. Access Control Matrix Operations • System can transition from one ACM state to another • Primitive operations: create subject, create object; destroy subject, destroy object; add access right; delete access right • Transitions are, of course, conditional

15. Access Control Lists (1) Simplify access rights management by storing the access control matrix a column at a time along with the resource to which the column refers. ACLs are widely used in environments where the users manage the security of their own files such as Unix systems.

16. Access Control Lists (2) Advantages: • Easy to understand • Easily answer the question "who has what kind of access to this resource“ • Work well in distributed systems; Rights stored together with resources Disadvantage: • May be inefficient. Determining rights may require searching a long list

17. Groups and Roles Staff in large organizations usually fit into a small number of categories, staff need to be assignable to a small number of groups or functional roles. A group is a list of principals. A role is a fixed set of access permissions that one or more principals may assume for a period of time. e.g. “root”, “super user”, “administrator”

18. Efficient use of ACLs (1) • Groups, to shorten lists • Rules if someone (through groups) appears twice in a list with different rights • “Access: None” to create a temporary smaller group out of an existing large one • Specific system manager rules These points are demonstrated by example below. They can be extended to Role Based Access Control data bases which are discussed later.

19. Efficient use of ACLs (2) Groups in ACLs – Group1: Alice, Bob, Cynthia, David, Eve – Group2: Alice, Bob, Cynthia, David – Group3: Bob, Cynthia, David, Eve – File 1: Group 1, R; Group 3, RW Suppose Eve wants to write to File 1 • First relevant entry policy: Access denied • Any permission in list policy: Access allowed

20. Efficient use of ACLs (3) “First relevant entry” rule in ACL • Efficient (shorter searches on the average compared to “Any permission”) • Order in ACL crucial • Effect of additions/deletions to list depends entirely on previous/later items • Efficient use of already existing groups is possible

21. Efficient use of ACLs (4) “First relevant entry” effects Group1: Alice, Bob, Cynthia, David, Ron Group2: Alice, Bob, Cynthia, David, Eve File 1: Group1, R; Group2, R;………; Ron, RW • The effect of “Remove Group2, R” is that everyone except Eve can still read the file • Ron’s entry has no effect. He cannot write. • The only effect of “Remove Group1, R” is that Ron gets his write permission! • Placing Ron’s entry first slows down list search

22. Efficient use of ACLs (5) “Any permission” rule in ACL • Longer search (always until a permission is found or list exhausted) • Efficiency depends on order in ACL (frequent users should be first in list) • Removal of one permission may be without effect

23. Efficient use of ACLs (6) “Any permission” effects Group1: Alice, Bob, Cynthia, David, Ron Group2: Alice, Bob, Cynthia, David, Eve File 1: Group1, R; Group2, R;………; Ron, RW • Finding Ron’s write permission takes time • Remove “Group2, R”! and everyone except Eve can still read the file

24. Efficient use of ACLs (7) “Access: None” • Group1: Alice, Bob, Cynthia, David, Eve • Group2: Alice, Bob, Cynthia, David • File 1: Group1, RW • File 2: Group2, RW is equivalent to • Group1: Alice, Bob, Cynthia, David, Eve • File 1: Group1, RW • File 2: Eve, None; Group1, RW In this way Eve is denied access to File 2 without the need for a Group 2 to be explicitly defined.

25. Efficient use of ACLs (8) Unix Operating System Access Control Lists (1) In Unix, and its variant Linux, files are only allowed rwx attributes for the resource owner, the group, and the world. The access control list as normally shown has a flag to show whether the file is a directory, then r, w, x flags for the owner, group, and world. For a directory with all the flags set the ACL looks like: drwxrwxrwx Alice Accounts N.B. “d” indicates “directory” or “folder”

26. Efficient use of ACLs (9) Unix Operating System Access Control Lists (2) An example with an FTP client

27. Efficient use of ACLs (10) Unix Operating System Access Control Lists (3) The list -rw-r---- Alice Accounts states the file is not a directory, the file owner Alice can read and write to it, the members of the group Accounts can read it but not write to it, non-group members have no access to it. N.B. -rwxrwxrwxowner, GROUP, others

28. Efficient use of ACLs (11) Unix Operating System Access Control Lists (4) an html file for www -rwxr-x-r-x index.html The user can write/read and execute, but group members and others can read and execute only. an executable programme -rwx--x--x game.exe N.B. drwxrwxrwxowner, GROUP, others See also “http://en.wikipedia.org/wiki/Attrib”

29. Efficient use of ACLs (12) Unix Operating System Access Control Lists (5) While a directory for web materials are set to: drwx----- web and an html file under the directory is set to: -rwxr-xr-x index.html Can a visitor to the site read the file? << hierarchical access control : “AND”, “OR”

30. Efficient use of ACLs (13) Unix Operating System Access Control Lists (6) Permission bits – mode If you wish to set an html file “index.html” with -r-xr-xr-x index.html Access control (= attribute), a command “chmod” is used. chmod 555 index.html 555 means 101(2) 101(2) 101(2) Owner: rx Group: rx Others: rx enabled. When the owner wants to make an amendment, you need to fire “chmod 755 index.html” - 7 means 111(2) rwx enabled.

31. Efficient use of ACLs (14) Unix Operating System Access Control Lists (7) Permission bits – mode Window XP “Attributes”

32. Efficient use of ACLs (15) System administrator (1) • Usually the system administrator has default maximum privileges o This is the “root” in Unix where the root userid is usually made available to the system administrator • Often no checks are made for access as system administrator • Sometimes specific rights are given to the system administrator in the ACL, meaning there are things on the system administrator only they can do

33. Efficient use of ACLs (16) System administrator (2) • System administrators can normally give themselves any privilege they don’t already have o This means it is difficult to implement an audit trail as a file the system administrator cannot modify o However, when a system administrator gives themselves a privilege they were not assigned that event should be logged in non-erasable form • The simplest and most common way to protect the system log file from being compromised by the system administrator is to keep it separate, this means sending it to another machine administered by someone else

34. Efficient use of ACLs (17) Owner • Usually the creator of an object has default maximum privileges for the object • Granting access to others is one of those privileges • Sometimes only the owner and system administrator can ever change the ACL for the object • Some systems allow ACLs to have ACLs

35. Capabilities and the full matrix (1) An access control matrix may be stored by rows called capabilities. • A list is of course just the contents of a row of the access control matrix • Tickets and attribute certificates are subsets of this. o Tickets etc. do not reveal the subjects full permissions to the checking party

36. Capabilities and the full matrix (2) Capability lists The strengths and weaknesses of capabilities are more or less the opposite of ACLs. Capabilities were first presented as actual lists per subject. The main problem with capabilities is that changing a program’s status, for example so no user may execute it, can be difficult because it can be hard to find out which users have permission to execute the program. This equally applies to changing a files status and can be a problem when investigating an incident or preparing evidence of a crime.

37. Capabilities and the full matrix (3) Capability lists Capabilities are now commonly implemented in the form of tickets or attribute certificates. Attribute certificates are closely related to public key certificates which will be covered in detail later. Attribute certification in essence is a way of extending authentication-oriented use of PKI to support tasks related to authorization. Attribute Certificates provide a solution to certify binding of attributes to a given subject.

38. Capabilities and the full matrix (4) Capability lists Some operating systems (e.g., KeyKOS, EROS, IBM AS/400, Mach) combine the notion of an object’s name/reference that is given to a subject and the access rights that this subject obtains to this object into a single entity: capability = (object-reference, rights) Capabilities can be implemented efficiently as an integer value that points to an entry in a tamper-resistant capability table associated with each process (like a POSIX file descriptor). Capabilities can include the right to be passed on to other subjects. This way, S1 can pass an access right for O to S2, without sharing any of its other rights. Problem: Revocation?

39. Temporal Access Control (1) • Permit access only at certain times • Model: time-locks on bank vaults • Obvious way to implement: add extra fields to ACL

40. Temporal Access Control (2) Problems and Attacks • Is your syntax powerful enough for concepts like holidays; on what calendar? • What if the clock is wrong? • Can the enemy change the clock? • How is the clock set; by whom or what?

41. Temporal Access Control (3) Access Control at the Middleware Level (1) It is common for enterprises to have critical databases containing highly sensitive information such as credit card numbers. As an operating system sees a database as a single large file all it can do is identify legitimate users of the database and distinguish the database from the other applications running on the same machine. Database products such as Oracle have their own access control mechanisms which, in general, being modelled on operating system access controls use a mixture of ACLs and capabilities.

42. Temporal Access Control (4) Access Control at the Middleware Level (2) Nevertheless, the architecture of database access controls is usually more complicated than that of operating system access controls in the sense of their being more types of privileges. This is because database access controls involve higher levels of abstraction that access controls applied to files or processes.

43. Temporal Access Control (5) Smashing the stack Many technical attacks on operating systems involve memory overwriting attacks known as smashing the stack. Programmers are often careless about checking the size of arguments. A classic example was, a vulnerability in the Unix finger command. An implementation of this would accept an argument of any length but only 256 bytes had been allocated for the argument by the program. When an attacker used the command with an argument longer than 256 bytes the trailing bytes of the argument were executed by the CPU.

44. Temporal Access Control (6) Buffer Overflow Trying to write a segment of data over a memory location that does not have enough space. i.e. data size > memory size A segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (for example, attempting to write to a read-only location, or to overwrite part of the operating system). If the overflow goes into the system memory area that controls the overall operation of the computer/system, it could cause more critical problems.

45. Temporal Access Control (7) Stack Overflow (1) Besides changing values of unrelated variables, buffer overflows can often be used (exploited) by attackers to cause a running program to execute arbitrary supplied code. The techniques available to an attacker to seek control over a process depend on the memory region where the buffer resides, for example the stack memory region, where data can be temporarily "pushed" onto the "top" of the stack, and later "popped" to read the value of the variable.

46. Temporal Access Control (8) Stack Overflow (2) Typically, when a function begins executing, temporary data items (local variables) are pushed, which remain accessible only during the execution of that function. The simplest and most significant method of exploiting a stack based buffer overflow is to overwrite the function return address with a pointer to attacker-controlled data (usually on the stack itself).

47. Temporal Access Control (9) Stack Overflow (3) http://en.wikipedia.org/wiki/Stack_buffer_overflow

48. Temporal Access Control (10) Other technical attacks (1) SQL injection is a code injection technique. It commonly arises when a web developer passes user input to a database without filtering it to see if it contains SQL code.

49. Temporal Access Control (11) Other technical attacks (2) Format string attacks arise from the use of unfiltered user input as the format string parameter in certain C functions that perform formatting, such as printf(). o E.g. a programmer tries to print user supplied data and allows the print command printf() to interpret any formatting instructions, such as n%, contained in the user’s data. o A malicious user could write arbitrary data to arbitrary locations using the %n format token, which commands printf() and similar functions to write the number of bytes formatted to an address stored on the stack.

50. Temporal Access Control (12) Other technical attacks (3) Race conditions are where a transaction is carried out in two or more stages and it is possible for an attacker to alter it after the stage that involves verifying access rights. For example, Unix command mkdir (make directory: mkdir <name>)used to work in two steps. Firstly, storage was allocated and then ownership was transferred to the user. A user could initiate mkdir in the background and if this completed only the first step before being suspended, a second process could be used to replace the newly created directory with a link to the password file. Then the original process would resume and change the ownership of the password file to the user.