Transcript Lecture 2 - Nipissing University Word

Lecture 2
Access Control
1
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
2
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.

3
Password

Threats for Identification




To avoid attacks such as



Exhaustive search
Intelligent search
Defense:





4
Password guessing
Password spoofing
Compromise of the password file.
Set a password
Change default password
Password length
Password format
Avoid obvious passwords
System help
 Password
checkers
 Password generation
 Password ageing
 Limit login attempts
 Inform users
5
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.
6
Protecting the Password
file
 Cryptographic
protection
 Access Control enforced by the OS
 Combination
7
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:














8
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.
Examples

Invalid or poorly chosen passwords:






Strong passwords (the following are for example
purposes only; do not use any of these examples as
your actual password):



9
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.
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).
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:

Where you are
 Which
10
form, speed, pressure,
terminal, which client, registered position
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
11
(restrictions on read access)
 integrity (restrictions on write access)
 availability
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
12
Reference
Monitor
System
Decision
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)

13
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
14
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,
15
directories, printers
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

16
Fact file




17
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
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’)

18
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
19
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
20
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





25
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
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

28
It depends on policy whether the process can
delegate her uid to other processes, but usually it
is not an option to ask Alice
Access operations
 An
interaction between an object and a
subject
 A subject may observe (read) an object
 Information
 A subject
may alter (write to) an object
 Information
29
flows from object to subject
flows from subject to object
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


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


31
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
Rarely useful (audit log files being the main exception)
Implemented in Multics
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
 Read
access
(list directory contents)
 Write (create or rename files in directory)
 Execute (search directory)
33
UNIX ls command
Operations
Owner Group
Size
Updated
Name
drwxr-xr-x
jason
Research
512
Jul 3 15:51
Research
-rw-------
jason
research
127092
Aug 28 15:01
Trash
-rwxr-xr-x
jason
research
7632
May 20 18:16
a.out
-rw-r-----
jason
research
0
Nov 25 1998
allfiles.txt
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
35
of 9 bits in 3 groups of 3
The UNIX reference
monitor

The access mask of the Research directory
is 101 101 111 representing x-r x-r xwr
 The
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
ls output reverses the order of the bits
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
jason
mick
37
trash
a.out
allfiles.txt
{r,w}
{r,w,x}
{r,w}
{r,x}
{r}
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
38
belongs to the access matrix entry
corresponding to subject s and object o
The access control
matrix
request (jason, allfiles.txt, w) is
granted
 The request (mick, allfiles.txt, w) is
denied
 The
Objects
Subjects
jason
mick
39
trash
a.out
allfiles.txt
{r,w}
{r,w,x}
{r,w}
{r,x}
{r}
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
jason
mick
41
trash
a.out
allfiles.txt
{r,w}
{r,w,x}
{r,w}
{r,x}
{r}
Access control lists
 Access
control lists focus on the
objects
 Typically
implemented at operating system
level
 Windows NT uses ACLs
 Disadvantage
 How
can we check the access rights of a
particular subject efficiently (“before-theact 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
jason
mick
43
trash
a.out
allfiles.txt
{r,w}
{r,w,x}
{r,w}
{r,x}
{r}
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
47
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
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
49
VSTa, a complicated hierarchical group
structures can be constructed based on the UNIX
model (Andrew Valencia http://www.vsta.org:8080/ )
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
50
Example




Objects are bank
accounts
Subjects are bank
employees
The set of bank
accounts forms a data
type
We define roles



51
Teller
Clerk
Administrator

We define procedures for





Crediting accounts (CA)
Debiting accounts (DA)
Transferring funds between
accounts (TF)
Creating new accounts (NA)
Authorising overdrafts (AO)
Example
 We
assign procedure
 CA and
DA to the Teller role
 TF to the Clerk role
 NA and AO to the Administrator
role
 We
assign all users who are
tellers to the Teller role, etc.
 The Administrator role can run
all the procedures
52
Admin
Clerk
Teller
Benefits of RBAC (RoleBased Access Control)
 We
only need to assign users and
permissions to roles
 We can use inheritance in the role
hierarchy to reduce the number of
assignments that are required
 Simplifies administration
53
RBAC models
 NIST
(Ferraiolo et al., 1992-2000)
 RBAC96 (Sandhu et al., 1996)
 ARBAC97 (Sandhu et al., 1997-99)
 OASIS (Hayton et al., 1996-2001)
 Role Graph model (Nyanchama and
Osborn, 1995-2001)
 Unified RBAC96 NIST model
(Ferraiolo, Sandhu et al., 2001)
54
RBAC implementations

Roles implemented in
 Window
NT (as global and local groups)
 IBM’s OS/400
 Oracle 8 onwards
 .NET framework

There is no generally accepted standard for
RBAC
 Role
hierarchies
 Semantics of role hierarchies
55
My Research on Roles

In society, a role is a wrapper of a user to
view the world.
Incoming
Messages
Service
interface
Request
Interface
Top Package::Top
A Human Package
in
Collaboration
56
Outgoing
Messahes
My Research on Roles
In
a system, a role is an interface between a user and a
system.
...
...
role
57
A collaborative
system including
objects, agents,
groups and roles
New challenges
How
do we “do” access control
if we can’t identify subjects?
How do we control the access
of untrusted code running on
our machine?
58
.NET security
 Evidence-based
access control
 Location
 Code
identity
 Code author
 Proof carrying code
 Role-based
security
 Authentication
 Authorisation
59
(access control)
Java security
 Protection
domains
 The
scope of a protection domain is the
set of objects accessible by a subject
 System domains
 Application domains (sandboxes)
 Signed
applets
 Digitally
signed code that can be trusted
by the host
60
Summary
 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

61