Lecture 2

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

System Decision

Reference Monitor

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

22

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

23

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.

24

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’)

25

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

26

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

27

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

28

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

29

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

30

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”

31

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

32

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

33

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)

34

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

35

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

36

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

37

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

trash a.out allfiles.txt

jason {r,w} {r,w,x} {r,w}

mick {r,x} {r}

ObjectsSubjects

38


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

39


The request (jason, allfiles.txt, w) is granted

The request (mick, allfiles.txt, w) is denied



mick {r,x} {r}

ObjectsSubjects

40

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)

41

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)?



mick {r,x} {r}

ObjectsSubjects

42

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-the-act per-subject review”)?

43

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)?



mick {r,x} {r}

ObjectsSubjects

44

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”)?

45

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)

46

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

47

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

48

Aggregation techniques User groups Roles Procedures Data types

49

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 Valencia http://www.vsta.org:8080/ )

50

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

51

Example Objects are bank

accounts Subjects are bank

employees The set of bank

accounts forms a data type

We define roles 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)

52

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

Admin

Clerk

Teller

53

Benefits of RBAC (Role-Based 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

54

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)

55

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

56

My Research on Roles In society, a role is a wrapper of a user to

view the world.

Top Package::Top PackageA Human inCollaboration

IncomingMessages

Serviceinterface

RequestInterface Outgoing

Messahes

57

My Research on Roles

role

. . .

. . .

A collaborative system including objects, agents, groups and roles

In a system, a role is an interface between a user and a system.

58

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?

59

.NET security Evidence-based access control

Location Code identity Code author Proof carrying code

Role-based security Authentication Authorisation (access control)

60

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

61

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

Documents

Lecture 2