Transcript Lecture 3
EE5552 Network Security and Encryption
block 3
Dr. T.J. Owens Cmath, FIMA, MIEEE Dr T. Itagaki MIET, MIEEE, MAES
Block 3 Access Control
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
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
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
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
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.
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.
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.
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: Alice Bob Carol David Eve Data 1 RW R RW Data 2 RW R R R Program 1 Program 2 E RWE E E RWE RE
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 Alice Bob Carol David Eve Data 1 RW R RW Data 2 RW R R R Program 1 Program 2 E RWE E E RWE RE
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
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
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
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.
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
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”
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.
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
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
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
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
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
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.
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”
Efficient use of ACLs (9)
Unix Operating System Access Control Lists (2)
An example with an FTP client
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. -
rwx rwx rwx owner
,
GROUP, others
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. d
rwx rwx rwx owner
,
GROUP, others
See also “http://en.wikipedia.org/wiki/Attrib”
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”
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.
Efficient use of ACLs (14)
Unix Operating System Access Control Lists (7)
Permission bits – mode Window XP “Attributes”
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
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
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
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
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.
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.
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?
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
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?
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.
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.
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.
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.
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.
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).
Temporal Access Control (9)
Stack Overflow (3) http://en.wikipedia.org/wiki/Stack_buffer_overflow
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.
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.
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
Temporal Access Control (13)
Other technical attacks (4)
A wide variety of bugs have enabled users to assume root status (system administrator) and take over the system. Some Unix implementations had the feature that if a user tried to execute the command su (super user login) when the maximum number of files were open, then su was unable to open the password file, and responded by giving the user root status.
There have been a number of bugs that allowed denial of service attacks.
Temporal Access Control (14)
Other technical attacks (5)
Until the late 1990s most implementations of the Internet protocols allocated a fixed amount of buffer space to process SYN packets with which TCP/IP connections are initiated. This led to SYN flooding attacks. By sending a large number of SYN packets, an attacker could exhaust the available buffer space and prevent the machine accepting any new connections. This is now fixed using syncookies.
Temporal Access Control (15)
User interface failures (1)
One of the earliest attacks was the Trojan Horse, a program the administrator is invited to run that will cause harm if run. Attackers wrote games that checked occasionally if the player was the system administrator, and if so would create another administrator account with a known password.
Perhaps the most serious example of user interface failure in terms of the number of systems at risk is in Windows NT.
Temporal Access Control (16)
User interface failures (2)
In this operating system, a user must be the system administrator to install anything. This is useful in preventing staff from loading up viruses. However, in many working environments staff must be able to install software to get their work done. In practice this has resulted in millions of people having administrator privileges who should not need them. These people are vulnerable to attacks in which malicious code pops up in a box telling them to do something.
Temporal Access Control (17)
User interface failures (4)
Microsoft’s solution is User Account Control. Introduced in Windows Vista and Windows Server 2008 operating systems, User Account Control limits the use of application software to standard user privileges until an administrator authorizes higher privileges. Only applications trusted by the user can receive administrative privileges as the user has to request these privileges. However, this requires care to implement properly.
Temporal Access Control (18)
User interface failures (4)
Furthermore, it provides no protection where applications such as web servers must run as root, are visible to the outside work, and contain software bugs that allow them to be taken over.
To reduce the possibility of lower-privilege applications communicating with higher-privilege ones User Interface Privilege Isolation is used in conjunction with User Account Control to isolate these processes from each other. One prominent use of this is Internet Explorer 7's "Protected Mode".
Temporal Access Control (19)
Remedies
See http://en.wikipedia.org/wiki/Buffer_overflow http://en.wikipedia.org/wiki/Stack-smashing_protection
The principle of least privilege (1)
From: http://hissa.nist.gov/rbac/paper/node5.html
The principle of least privilege requires that a user be given no more privilege than necessary to perform a job.
Ensuring least privilege requires identifying what the user's job is, determining the minimum set of privileges required to perform that job, and restricting the user to a domain with those privileges and nothing more. By denying to subjects transactions that are not necessary for the performance of their duties, those denied privileges cannot be used to circumvent the organizational security policy.
The principle of least privilege (2)
From: http://hissa.nist.gov/rbac/paper/node5.html
Through the use of Role Based Access Control (RBAC), enforced minimum privileges for general system users can be easily achieved.
It can also be applied to processes on the computer; each system component or process should have the least authority necessary to perform its duties. This helps reduce the "attack surface" of the computer by eliminating unnecessary privileges that can result in network exploits and computer compromises.
The principle of least privilege (3)
From: http://hissa.nist.gov/rbac/paper/node5.html
In particular, programs should only have as much privilege as necessary. Software should be designed so that the default configuration, and in general, the easiest way of doing something, is safe. The main function of access control in computer operating systems is to limit the damage that can be done by particular, groups, users, and programs, whether through error or malice.
home work
• • • • Unix “chmod” command DOS/OS 2 “attrib” command with /r /a /s /h see also http://en.wikipedia.org/wiki/Chattr Windows – file attribute