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