1

Access Control & SecurityModels

Simone Fischer-HübnerComputer Security 2008

Fundamental Model for Access Control

Subject Access request

ReferenceMonitor

(access controlpolicy)

Object

Access operations in Unix

Directory searchExecuting a program file

execute

Create or rename a file in the directory

Writing to a filewrite

List directorycontents

Reading from a file

read

Applied to directories

Applied to filesAccess operation

Grouping of entities

It is simpler to define access control

policies with:

� Groups (sets of users)

or

� Roles (sets of application-specificoperations)

DAC & MAC (1)

Discretionary Access Control (DAC):

� Subjects (e.g. users) at their own discretion can specify to the system who can access their objects (e.g. files)

� Restriction of access to objects based on the identity of the subject/ or subject-group

Drawback:

DAC is, by its nature, subject to Trojan Horse Attacks

DAC compromisd by Trojan Horse

Alice

GAME.exe(Trojan)

executes

Access Control entries for Alice’s file Secret.dat:

read, writeAlice

modifies

..... ....

Secret.dat

owns

Eve read

2

DAC & MAC (2)

Mandatory Access Control (MAC):

� Users and files have fixed security attributes that are used by the system to determine whether a user can access a file

� Security attributes are set by security administrator or automatically by the system

� Security attributes cannot be modified by users or their programs

DAC & MAC (3)

Example: Military (Multi-level) Security Policy:� Security levels that are in a linear or partial order are taken

as security attributes� Security levels of subjects are called clearances� Security levels of objects are called classifications

A subject S may read object O, if:clearance (S) > classification (O)

Subject S may write-access object O, ifclearance (S) < classification (O)

(see Bell LaPadula-Model)

Access Control Structures (1)

Access Control Matrix:S: set of subjectsO: set of objectsA: set of access operations

M = (Mso)s∈S, o∈O with Mso ⊂ A.

Example:

{execute, read, write}{execute}{read, write}Bill

{execute, read}{execute}-Alice

Fun.comEdit.exeBill.doc

Abstract concept, not suitable for direct implementations

Access Control Structures (2)

Access Control Lists (ACL):� Corresponds to a column of the access control matrix� Stores access rights to an object with the object itself� Typically used to protect owned objects such as files

Directory entries

Fun.com

Fun.com

Alice

Bob

execute, read

execute, read, write

ACL

Problems:Difficult to get an overview of permissions given to an individual user

Access Control Structures (3)

Capabilities:� Correspond to subjects’ rows in the access control matrix� Unforgeable tokens that specify the holders’ (subjects’) access rights� Typically associated with DAC� Suitable for distributed systems

Alice’s capability: edit.exe: execute; fun.com: execute, read

Bill’s capability: bill.doc: read, write; edit.exe: execute;

fun.com: execute, read, write

Problems:� Difficult to give an overview of who has permission to access a given

object� Difficult to revoke a capability� Special protection needed

New Paradigm: Certificate-based access control

� Today increasingly access requests to servers by remoteunknown users

� Traditional seperation between authentication and access control cannot be applied

� Digital certificates (or credentials) can be used to proveproperties of their holders (e.g., authorisations)

� Certificate issuer assigns authorisation to certificate holderthrough his signature

Alice’s public key, authorisation to use service X

Signed by issuer

3

Example: SPKI (Simple Public Key Format and Infrastructure) Certificates:

Digitally signed record which may be expressed as a 5-tuple (I, S, D, A, V) where

� I = public key or a hash of the public key of the certificate’s issuer

� S = subject acquiring the authority (typically its public key, hash of a public key)

� D = delegation bit indicating whether the subject has the right to further delegate the rights granted in this certificate

� A = authorisation field specifying the permissions granted by the issuer to the subject

� V = validity field of the certificate.

Purpose: to communicate permission from one keyholder to another

SPKI - Example

1) The bank wants to grant Alice on-line access to her account:

(KB, KA, yes, access to account X, always)signed by Bank

->with this certificate, Alice can access her account if she proves to hold the private key corresponding to KA.

2) Alice can give Carl the right to pay her bills while she is on vacation:

(KA, KC, no, access to account X for paying bills, vacation period) signed by Alice

->with the chain of the 2 certificates, Carl can pay the bills if he proves to hold the private key corresponding to KC.

KA: Alice’s public key

KB: The bank’s public key

KC: Carl’s public key

Security Models - Introduction

� Security Models needed to formulatesecurity policies

� Many security models are state machinemodels

State machine models (1)

State machine model: describes a system as an abstract mathematical state machine with:

� state variables representing the system state

� transition functions describing how the state variables (i.e. system state) change

State machine models (2)

Steps in developing a “secure” state-machine model:

1.) Define the security-relevant state variables (subjects, objects,

security attributes, access rights, etc.)

2.) Define the conditions for a secure state (“security properties”)

3.) Define state transition functions (e.g., create subject, create object, get access, revoke access)

4.) Prove that the functions maintain the secure state

5.) Define the initial state

6.) Prove that the initial state is secure in terms of the definition of the secure state

=> By induction it can be proven that every system state is secure

The Bell LaPadula Model(Mitre, 1973)

� Most famous security model

� State machine model

� Captures confidentiality aspects of access control

� Prevents information to flow ”downwards”from a high to a low security level

4

The Bell LaPadula Model –State variables

Variables:

� a set of subjects S

� a set of objects O

� a set of access operations A = {e:execute, r:read, a:append, w:write}

� a set of L of security levels with a partial ordering <

The Bell LaPadula Model –Access rights

xxalter

xxobserve

w:writer:reada:appende: execute

Access modes

Access rights

Bell LaPadula Model –Security Levels (1)

Security Levels contain of linearly ordered classifications:

unclassified

confidential

secret

top secret

However: Linearly ordered classifications alone are not expressive enough:

E.g. they cannot restrict access to a ”secret” project X just to the persons working on X (”need-to-know”).

Security level = (classification, set of categories)

Classifications: C1, C2, C3, C4,… (used to enforce least privilege)with C1 < C2 < C3 < C4 (linear order)

e.g.: unclassified < confidential < secret < top secret

Categories: K1, K2, K3, ...(used to enforce need-to-know)

e.g. Nuclear, Nato, Crypto

Example of a security level: (secret, {Nato, Crypto})

The Bell LaPadula Model –Security Levels (2)

For enforcing the ”need-to-know” principle, security levels also contain a set of categories:

The Bell LaPadula Model –Security Levels (3)

Security level-1 : (class-1, category-set-1)> (“dominates”)

Security level-2 : (class-2, category-set-2)⇔

class-1 > class-2 ∧ category-set-1 ⊇ category-set-2

Example:(top secret, {Nato, Crypto}) > (secret, {Nato})

The Bell LaPadula Model –Security Levels (4)

The relation “>“ (“dominates”) is a partial ordering: It is(1) reflexiv: Lu > Lu

(2) antisymmetric: Lu > Lv ∧ Lv > Lu ⇒ Lu = Lv

(3) transitive: Lu > Lv ∧ Lv > Lw ⇒ Lu > Lw

for levels Lu, Lv, Lw

Remark: A mistake you might make is to assume:If not (Lu > Lv ) then Lv > Lu.

Partially ordered security levels could be incomparable, e.g.:

(secret, {Nato}), (top secret, {Crypto})

5

Bell LaPadula Model –Security Levels (5)

� Partially ordered security levels form a lattice.� Example: Security levels composed of

� Classifications: private, public� Categories: PER (personnel), ENG (engineering)

public, Ø

Public, {PER, ENG}

private, Ø

private, {PER, ENG}

Public, {ENG}Public, {PER}

private, {PER} Private, {ENG}

The Bell LaPadula Model –System state

� System state captures all currentpermissions and all current instances of subjects accessing objects

� System state: (b, M, f)

� b: set of current accesses

� M: Access permission matrix

� f: Security Level function

The Bell LaPadula Model –Current access set

Current access set b:

Set of tuples (s, o, x),

indicating that subject s currently performsoperation x on object o.

The Bell LaPadula Model –Access permission matrix

Access permission matrix M:The component MSO records the access rights with which subject s is permitted to access object o (according to Bell LaPadula’s discretionary access control policy)

Subjects

Objects

MSO

S

O

r

The Bell LaPadula Model –Security Level function

Security level function f: (fS, fO, fC)

fs: S � L gives the maximal security level eachsubject can have,

fc: S � L gives the current security level of eachsubject (fc < fs),

fo: O � L gives the security levels of all objects.

The Bell LaPadula Model –Simple security property

Conditions (”properties”) for a secure state:

Simple security (ss)- property (”no read-up”):

If (s, o, x) ∈ b, x ∈{r, w} =>

fO(o) < fS(s).

Subject

Object

High

Low

readSecurity level

6

Illegal information flow not addressedby simple security-property

High

Low

Securitylevel

Subject-1 (malicious)

Subject-2

Object-1

Object-2

Illegal Information Flow !

observe

alter

observe

The Bell LaPadula Model –*-property (1)

*-Property (”no write-down”):

If (s, o1, x1) ∈ b, x1 ∈ {r, w}

and (s, o2, x2) ∈ b, x2 ∈ {a, w} =>

fO(o2) > fO(o1)

The Bell LaPadula Model –*-property (2)

The *-property can be refined in terms of the current security level:

If (s, o, x) ∈ b =>

fO(o) > fC(s) if x = a

fO(o) = fC(s) if x= w

fO(o) < fC(s) if x = r

The Bell LaPadula Model –*-property

� How can a high-level subject send a message to a low-level subject ?

� Temporarily downgrade current securitylevel

� Exeptions from *-property for ”trustedsubjects”

The Bell LaPadula Model –ds-property

Discretionary Security (ds) -Property:If (s, o, x) ∈ b ⇒ x ∈ Mso.

Simple security- and *-properties are enforced by Mandatory Access Control (MAC)

ds-property is enforced by Discretionary Access Control (DAC)

The Bell LaPadula Model –Secure state transitions (1)

A state is called secure if simple security-, *-, and ds- properties are satisfied

A state transition from state

v1 = (b1, M1, f1) to state v2 = (b2, M2, f2)

is secure, if v1 and v2 are secure.

7

The Bell LaPadula Model –Basic security theorem

”Security” in terms of the security propteriescan be guaranteed, if:

the initial state is ”secure”

all state transitions are ”secure”

(=> every subsequent state will be ”secure”)

Excercise

What kind of access can a process with the current security level (secret, {NATO, CRYPTO}) have to documents classified in each of the following ways under the Bell LaPadula Model:

1.(top secret, {NATO })2.(unclassified, {CRYPTO, NATO})3.(top secret, {CRYPTO, NUCLEAR})4.(secret, {NUCLEAR, CRYPTO})5.(top secret, {NATO, CRYPTO, NUCLEAR})

Bell LaPadula Model –Discussion

� Only deals with confidentiality, not with integrity

� ”blind write” might cause integrity problems

� Exposed to covert channel attacks

� Implemented in Multics, Unix V/MLS, Trusted Oracle,....

Integrity Models

Integrity Goals:

� Data consistency (validity of data)

� Preventing unauthorised users from making modifications

� Preventing authorised users from making improper modifications

Biba Integrity Model (1977)

First Integrity Model, dual to Bell LaPadula

Model elements:S: set of subjectsO: set of objectsI: set of integrity levels (il) with a partial ordering

Access modes: o (observe), m (modify), i (invoke)

Biba Model – ”no read down”Security properties:

Simple Integrity-Property (“no read down”):∀s ∈ S, o ∈ O: s o o ⇒ il(s) ≤ il(o)

Subject

Object-1

High

Low

observe

Integrity level

Object-2modify

8

Biba Model – ”no write up”

Integrity *-Property (”no write up”):∀s ∈ S, o ∈ O: s m o ⇒ il(o) ≤ il(s)

Subject

Object

High

Low

modifyIntegrity level

Biba Model –invocation property

Invocation Property:∀s1, s2 ∈ S: s1 i s2 ⇒ il(s2) ≤ il(s1)

Subject-1

High

Low

Integrity level

Subject-2

invoke

Biba Model - Discussion

� Does not address data consistency

� Only prevention of modifications by

unauthorized users

� Authorized users can still make improper

modifications

� Problem to assign appropriate integrity levels

� Only implemented in few systems

Clark Wilson Integrity Model (1988):

Policy is based on two key concepts:

� Well-formed transactions

� Separation of duties

Clark Wilson –Model Description

State variables:

CDIs: Constrained Data Items

IVPs: Integrity Verification Procedures

TPs: Transformation Procedures

(transaction = transformation procedure +

permitted CDIs)

UDIs: Unconstrained Data Items (input data)

Clark Wilson - Rules

Two types of rules:

� Certification Rules (C) - performed by the security officer

� Enforcement Rules (E) - done by the system

9

Clark Wilson - Overview

TP TP

UDI

CDI

CDI CDI

CDI

CDI

CDI

CDI

IVP

IVP

.......

LogCDI

LogCDI

LogCDI

ACCESS TRIPLES

(UserID, TP-i, (CDI-a, CDI-b,...), …)

USER

SECURITY OFFICER

Valid Initial StateValid next state Valid final state

C1

C1

E4

C5

E3

E1

E2

C4

C3

C2

C2

ACCESS TRIPLES

(UserID, TP-i, (CDI-a, CDI-b,...), …)

SECURITY OFFICER

E4

Clark Wilson –Certification Rules

TPs validate UDIC5:

TPs write logC4:

Suitable separation of dutiesC3:

TPs preserve valid stateC2:

IVPs certify CDI are validC1:

Clark Wilson –Enforcement Rules

Authorisation lists (Access Triples) changed only by security officer

E4:

Users are authenticatedE3:

Users are authorized for TPsE2.

CDIs changed only by authorized TPsE1:

Clark Wilson - Discussion

� Access triples can

� prevent modifications by unauthorized users

� enforce separation of duties

� Separation of Duties Principle can prevent

authorized users from making improper

modifications

� IVPs and TPs can help to guarantee consistency

Role-Based Access Control (RBAC) - Introduction

� Developed at NIST/NSA since early nineties

� American National Standard - ANSI INCITS 359-

2004

� Implemented in SUN Solaris, SELinux, Oracle,

Sybase,...

See also: http://csrc.nist.gov/rbac/

Role-Based Access Control (RBAC) - Approach

Security administrator assigns:

� Membership of users to roles: user --> roles

� Privileges (operations) to a role:

role --> set of operations

10

RBAC - Example

A user in the role “doctor” may perform the following transactions:

� enter_diagnosis

� prescribe_medication

Doctor

Patient Record

Prescription

Objects Roles Users

Dr. Sara John

Dr. Peter Smithenter_diagnosis

prescribe_med

Operations

member_of

member_of

RBAC – Access rules

A subject S may access an object O with

operation op if

� S performs a role r

� S is authorised to perform r

� r is allowed to perform op

� op is allowed to access O

RBAC –Reduced Administrative Overhead

� Allocation of operations to a role remains relatively constant or changes slowly over time.

� The security administrator’s task consists simply

of granting and revoking memberships to the set

of specified roles.

� Roles can be composed of roles with an

inheritance of privileges

RBAC – Role Hierarchies

Doctor

Patient Record

Prescription

Dr. Sara John

Dr. Peter Smithenter_diagnosis

prescribe_med

Nurse

member_of

enter_blood_values Mary Jo

Su Chen

Example: ”Doctor” role inherits privileges of ”Nurse” role

member_of

member_of

member_of

RBAC – Cost savings

Annual cost savings : $6.924 a year for 1.000 employees

RBAC – Further features (1)

� Static Separation of Duties� by defining mutually exclusive roles

� e.g. in a bank the roles ”teller”, ”auditor” cannotbe authorised for the same user

� Dynamic Separation of Duties� By defining mutually exclusive activation of roles

� e.g. Roles ”Payment Initiator”, ”PaymentAuthoriser” can be performed by same user, butnot at the same time

11

RBAC – Futher features (2)

� Role Cardinality

� by defining a capacity for a role

� e.g. only one user is ”Manager”

RBAC - Features in Commercial

Database Management Systems

YESYESYESGRANT DBMS Object Privileges to a role

YESYESNOGrant DBMS System Privileges to a role

NONONOSpecify maximum or minimum cardinality for role membership

NOYES(YES)Specify dynamic separation of duty constraints on roles

NOYESNOSpecify static separation of duty constraints on roles

YESYESYESBuild a role hierarchy

YESYESNOSpecify a default active role set for a user session

YESYESNOMultiple active roles for a user session

YESNOYESAbility for a role grantee to grant that role to other users

OracleSybaseInformixFeature

XACML - Standard

� ”eXtensible Access Control Markup Language” –OASIS Standard

� It describes:� General Purpose Access Control Language

� Access Control Decision Request/Response Protocol

(both written in XML)

� Advantages of XACML:� It’s standard - widely deployed, enables interoperability

� It’s generic – can be used in any environment, one policy can be used by many different applications

� It’s distributed – a policy can refer to other policies kept in arbitrary locations maintained by other groups/people

XACML - Components

� Policy Enforcement Point (PEP) – the system entity that performs access control(e.g. file system, web server)

� Policy Decision Point (PDP) – the system entity that evaluates applicable policies and renders an authorisation decision

� Policy Information Point (PIP) – the system entity that acts as a source of attribute values

� Policy Administration Point (PAP) – the system that creates a policy or policy set

How XACML is working

PEPAlice

”read file Y”System File Y

PDPXACML policies

PAP PIP

Decision request:Subject-id: Alice

Resource-id: File Y

Action-id: Read

Response:PermitObligation: recordin an audit log

AdditionalAttributes:

Role: Secretary,..

Time: 9am

Attributes, Authorities,…

XACML - Policy Structure

PolicySet

Target:

PolicySet applies if….

Policy

PolicySet

Policy

Target:

Policy applies if….

Rule

Rule

Target:

Rule applies if….

Effect:

If satisfied, rulereturns {permit, deny,

NotApplicable, Indeterminate}

Conditions:

Rule is satisfied if….

Set of simplifiedconditions for

subject, resourceand/or action

12

Example: A Simple XACML Rule

<Rule Effect=”Permit”>

<Target>

File Y

<\Target>

<Condition>

<Apply FunctionID=”AND”>

Role=”Secretary”,

Action=”Read”,

Time > 7am,

Time < 5pm,

….

<\Apply>

<\Condition>

<\Rule>

Conflict Resolution Policy (Meta Policy)

� Deny-overrides

� Permit-overrides

� …

Exercise 2

Consider the following commercial security requirements:

1. Users of applications (e.g. accounting) will use application programs and databases (i.e. read the application program code and read and write to the databases); they will not write their own programs to operate on the databases

2. Application program developer will do their development and testing in a test environment, and have no access to the application (source or object) programs or databases. They have access to programming tools and test data (i.e. they can read the programming tool code and read/write test data).

� Discuss if/how this requirement can be enforced by Bell LaPadula, Clark Wilson and RBAC