Systems Security

Chapter 3: Security Policies and Models

Winfried E. Khnhauser
Summer Term 2016

Winfried E. Khnhauser
CSI
Ilmenau Technical University
www.tu-ilmenau.de
Systems Security, ST 2016 wk

-1-

Roadmap

Security Requirements

Security Policies
Modeling and Specification

Security Mechanisms

Security Architectures

Systems Security, ST 2016 wk

-2-

3 Security Policies and Models

3.1 Security Policies

A Traditional Scenario

Same as systems security: threats to valued assets:

human life, cargo, ship
The difference: Thousands of years of experience

we may learn something here

Systems Security, ST 2016 wk

-3-

3.1 Security Policies

What assets support security?

Navigation lights: Protection against collisions

Cannons: Protection against pirates
Reefs, drift anchors: Protection against bad whether

security mechanisms

Construction of hull (height, stability, position of ballast): Capsizing

Placement of security mechanisms (cannons in mast head, nav lights in the hold):
Effectiveness

security architecture
Watch: Protection against collisions
The art of sailing, regulations (reefing, running before the wind, setting of drift
anchors): Protection against bad weather
coordinated use of mechanisms

security policies
Systems Security, ST 2016 wk

-4-

3.1 Security Policies

A CS Scenario: Hospital Information Systems

Excerpt from an information flow policy
Dr. Brains

Dr. Bones

EPR
PatId

Anamn.

Sympt.

Sister Kathy

Apothecary

CT Lab

MR Lab

Diag

Medic.

Brother Tuck

Nursing

Diet

Paul Bocuse

Pathology

Citchen

Administration

Complete IF-Graph:
>> 10.000 legal (and necessary!) information flows
> 100 obvious conflicts (without transitiveness)
> 100 forgotten information flows
Systems Security, ST 2016 wk

-5-

ad-hoc-approaches fail
3.1 Security Policies

Security Policies: A First Definition

We have: risks

Storm, running aground, pirates

Violation of confidentiality of EPRs, integrity of bank accounts,

We infer: security requirements

Protection against storm force 12

Permitted information flows

We infer: a security policy

Rules for dealing with storms, watches, pirates

Rules for controlling information flows

Systems Security, ST 2016 wk

-6-

3.1 Security Policies

Security Policy:
A set of rules designed to meet a set of security objectives.

Security Objective:
A statement of intent to counter a given threat or to enforce a given
organizational security policy.
(Common Criteria for Information Technology Security Evaluation, seit 1996)

Policy Representations

Informal text
Formal model
Executable policy implementation

Systems Security, ST 2016 wk

-7-

3.1 Security Policies

Example 1
Excerpt from the Unix OS Security Policy

There are subjects (humans, processes) and objects (files, sockets, ...)

Each object has an owner

Owners control access permissions for their objects ( DAC)

There are 3 types of on permissions: r, w, x

For each object there are 3 subject classes, owner, group, others, for which
individual permissions can be granted

-rw-r--r-- 1 kuehnhauser vsbs 397032 2009-02-19 12:12

paper.pdf

Result
identity based, discretionary access control (IBAC + DAC)
high degree of individual freedom
global responsibility, limited horizon (see chapter 2.1.2)
Systems Security, ST 2016 wk

-8-

3.1 Security Policies

Example 2
Excerpt from a CSCW Policy

Internet

Authentication:
1. Each user must be identified based on
key certificates issued by EADS

Authorization:
2. Access to ProjectX files is granted only to the project staff (role-based access
control)
3. Changes to files are allowed only if both, the responsible engineer as well as the
project leader approve (second set of eyes principle, and role-based access
control)
4. No information must flow from ProjectX to Sales department (IF)

Communication:
5. For protecting integrity, confidentiality and authenticity, every communication is
encrypted
Systems Security, ST 2016 wk

-9-

3.1 Security Policies

Implementation of Security Policies

Alternatives

Integrated in system software

Operating Systems

Data Base Systems

Middleware platforms

Integrated in application systems

Systems Security, ST 2016 wk

- 10 -

3.1 Security Policies

Policy-controlled Operating Systems

Application

Application

Application

Application

Process

Process

Process

Process

File System

Policy Server

OS

S={s1,s2,s3}, O={o1,o2,so3}
...
command read(s,o)
if readm(s,o)
enter (s,o) in h;
oiO, (oi,o)C: delete read from m(s,oi);
oiO, oio: delete write in m(s,oi);
end if
end
...

Systems Security, ST 2016 wk

- 11 -

3.1 Security Policies

E.g. the SELinux Security Architecture

Application
Layer

Application Process

Application Process

Application Process

OS Interface (Application Programmers Interface (API))

OS
Services
OS
Layer

Process
Process
Management
Management

Filesystems

Filesystems

Sockets

...

Sockets

Security
Server
Policy

System-wide Resource Management

Processing
Resources

Memory
Resources

Communication
Resources

Components

Security Server: Policys runtime environment in kernels protection domain

Interceptors: complete interaction control

Systems Security, ST 2016 wk

- 12 -

3.1 Security Policies

Policy Installation in SELinux

Security Policy
1
2
3
!
4
5

allow sysadm_t
allow sysadm_t
allow insmod_t
allow insmod_t
allow insmod_t

insmod_exec_t:file !x_file_perms;!
insmod_t:process
!transition;!
insmod_exec_t:process
{entrypoint execute};!
sysadm_t:fd
!inherit_fd_perms;!
sysadm_t:process
!sigchld;!

Binary

Policy Compiler

OS Interface (Application Programmers Interface (API))

OS
Services

Process
Prozesse
Mgmt

Filesystems
Dateisysteme

Sockets
Sockets

...

Sec. Server

System-wide Resource Management

Processing
Resources

Systems Security, ST 2016 wk

Memory
Resources

Communication
Resources

- 13 -

3.1 Security Policies

Policy-controlled Microkernel Architectures

Secure
Application

Legacy
Legacy
Application
Legacy
Application
Application

Paravirtualized Legacy OS

Trusted
Loader

Trusted
Name Server

Trusted
GUI

Security
Policy

Microkernel

Systems Security, ST 2016 wk

- 14 -

3.1 Security Policies

Policy-controlled Applications
Embedded Policy

Application

Application

Application

Process

Process

Process

S={s1,s2,s3}, O={o1,o2,so3}
...
command read(s,o)
if readm(s,o)
enter (s,o) in h;
oiO, (oi,o)C: delete read from m(s,oi);
oiO, oio: delete write in m(s,oi);
end if
end
...

OS

Systems Security, ST 2016 wk

- 15 -

3.1 Security Policies

Policy-controlled Applications
Application-level Policy Servers

Application

Application

Application

Process

Process

Process

Policy Server
S={s1,s2,s3}, O={o1,o2,so3}
...
command read(s,o)
if readm(s,o)
enter (s,o) in h;
oiO, (oi,o)C: delete read from m(s,oi);
oiO, oio: delete write in m(s,oi);
end if
end
...

OS

Systems Security, ST 2016 wk

- 16 -

3.1 Security Policies

Policy-controlled Distributed Applications

Policy Servers embedded in Middleware

Application

Application

Process

Process

File Server

Policy Server
S={s1,s2,s3}, O={o1,o2,so3}
...
command read(s,o)
if readm(s,o)
enter (s,o) in h;
oiO, (oi,o)C: delete read from m(s,oi);
oiO, oio: delete write in m(s,oi);
end if
end
...

Middleware
OS

Systems Security, ST 2016 wk

- 17 -

3.1 Security Policies

Example: Web Services in Apache Axis-2/Tomcat Web Servers

AxisEngine

SOAP Request

Handler
1

Handler
2

Client

Handler
n

(by HTTP, JMS ...)

Transport
Sender

out flow
instanciates

Stub

MCreq

SOAP Reply

MCresp

Coordinator
OutInAxisOperation

instanciates

MCresp

instanciates
Handler
m

Handler
2

Handler
1

in flow

AxisEngine

Systems Security, ST 2016 wk

- 18 -

3.1 Security Policies

AxisEngine
SOAP Request

MCreq

Handler
1

Handler
2

SOAP Reply

Handler
n

MCreq

Message
Receiver

MCresp

Transport
Sender

Handler
m

Handler
2

Handler
1

Web Service

HTTP/JMS
Transport Utilities

AxisServlet

in flow

MCresp

out flow

AxisEngine

Systems Security, ST 2016 wk

- 19 -

3.1 Security Policies

Messages 3.1
The Part of Security Policies

Requirements
Engineering

Security
Requirements
Policy
Engineering

Security
Policy
Model
Engineering

Security
Model
Architecture
Engineering

Systems Security, ST 2016 wk

- 20 -

Security
Architecture

3.1 Security Policies

3.2 Security Models

Systems Security, ST 2016 wk

- 21 -

3.2 Security Models

The Linda-Test
Linda is a bright and active student, ... , lobbying in the students council,
... , participating in demonstrations, ...
o
o
o
X
o

Linda works as a bank clerk

...
Linda works as a bank clerk and is an active member in a feminist
group
...

subjective statements colored by individual experience

Systems Security, ST 2016 wk

- 22 -

3.2 Security Models

Goal of Formal Security Models

Impartial, precise representation of security policies

Explanation of (observed) phenomena

Why is this authorization scheme behaving in that manner?

Prediction (proof) of behavior and phenomena

Under this security policy it will never happen that ...

Systems Security, ST 2016 wk

- 23 -

3.2 Security Models

Methods

Abstraction from (usually too complex) reality: get rid of insignificant

details
computability and computation complexity

Getting precise: formal description of essentials

model analysis and implementation

Systems Security, ST 2016 wk

- 24 -

3.2 Security Models

Definition
A security model is a precise, in general formal representation of a
security policy.
The ambition is to analyze the behavior of a security policy and to be able
to prove essential properties

Systems Security, ST 2016 wk

- 25 -

3.2 Security Models

Model Spectrum
Going by the book, there are

Models for access control policies

Identity based access control (IBAC)

Role based access control (RBAC)

Attribute based access control (ABAC)

Models for information flow policies

Multilevel security (MLS)

Models based on non interference properties

Noninterference (NI)

In Reality, we frequently see

Hybrid models

Systems Security, ST 2016 wk

- 26 -

3.2 Security Models

3.2.1 Access Control Models

Formal Representations of Permissions to Execute Operations
on Objects

Reading files
Issuing payments
Executing Web services

Systems Security, ST 2016 wk

- 27 -

3.2.1 Access Control Models

Model Spectrum

Identity-based access control models (IBAC)

Rules based on the identity of individual subjects/objects
Ann is allowed to change file projectXfile

Role-based access control models (RBAC)

Rules based on roles of subjects in organizations
Ward physicians are allowed to read patient EPRs of their ward

Attribute-based access control models (ABAC)

Rules based on attributes of subjects and objects
Only AAA-classified shares may by bought for Templeton Trust

Orthogonally, access control can be

Discretionary or mandatory

Systems Security, ST 2016 wk

- 28 -

3.2.1 Access Control Models

Discretionary Access Control (DAC)

Individual users specify access rules to objects within their area of
responsibility
Example
Access control in many OSes (e.g. Unix, Windows)
Consequence
Individual users

Enjoy freedom wrt. to granting access rights

Are obliged to maintain conformity to organizations security policy

competence problem
responsibility problem
malware problem

Systems Security, ST 2016 wk

- 29 -

3.2.1 Access Control Models

Mandatory Access control (MAC)

System-wide rules apply that cannot be sidestepped by individual users
Example
See Hospital Information System above
Consequence

Limited individual freedom

In charge of security policy:

Clearly identified instance

Competent

Responsible

No responsibility of individuals

Systems Security, ST 2016 wk

- 30 -

3.2.1 Access Control Models

In Reality we frequently see

Hybrid models with discretionary and mandatory components; e.g.
Discretionary: within a project, members individually define the
permissions wrt. documents
Mandatory: only documents authorized by the security policy can be
accessed from outside the projects security domain

Systems Security, ST 2016 wk

- 31 -

3.2.1 Access Control Models

3.2.1.1 Identity Based Access Control Models (IBAC)

Basic Paradigm
There are
Subjects: active and identifiable entities that execute
Operations on
Objects

Subject

Operation

Object

process reading a file

Web server accessing html page
client transfers money from Bank account

Access rights

Control execution of operations

Refer to identity of subjects and objects

Systems Security, ST 2016 wk

- 32 -

3.2.1.1 Identity Based Models

3.2.1.1.1 Access Control Functions and Matrices

Access Control Functions (Lampson 1970)
Basic model to define access rights

WHO (subject) is allowed to do WHAT (operation) on WHICH object

Fundamental to OS access control since 1965 (Multics OS)
Model paradigms: sets and functions

The Model: a Tuple (S,O,A,f)

Subjects modeled by a set S (users, processes)

Objects modeled by a set O (files, sockets, EPRs ...)
Access operations modeled by a finite set A (actions; read, write, )
Rights to execute operations modeled by an access control function f:
f : S x O x A {granted, denied}

Systems Security, ST 2016 wk

- 33 -

3.2.1.1.1 Access Control Functions and Matrices

Example
Modeling access rights for Web Services
Model: (S,O,A,f) where
S = {Bosch, VDO, Siemens} as set of subjects
O = {deliveryTime_WS} as set of objects
A = {see, execute, update} as set of operations
f: S x O x A {granted, denied} as access control function where e.g.
f(Bosch, deliveryTime_WS, see) = granted
f(Bosch, deliveryTime_WS, execute) = granted
f(Bosch, deliveryTime_WS, update) = denied
f(VDO, ...

Systems Security, ST 2016 wk

- 34 -

3.2.1.1.1 Access Control Functions and Matrices

Example
Access control model of the Unix OS (extremely simplified)
Model: (S,O,A,f) where
S: set of users
O: set of system objects (files, directories, sockets, )
A: set of system calls
f: implemented in system calls e.g. for accessing files:
{ s=caller.euid;
if (s==o.inode.owner and a_mode in o.inode.ownerRWX) then
return OK
else {
g=caller.egid;
if (g==o.inode.group and a_mode in o.inode.groupRWX) then
return OK
else
Systems Security, ST 2016 wk

- 35 -

3.2.1.1.1 Access Control Functions and Matrices

Access Control Matrices

Access Control Functions in Practice
f : S x O x A {granted, denied}

m: S x O 2A where a m(s,o) f(s,o,a) = granted

Lampsons access control matrix (ACM): a tuple (S, O, m)

Systems Security, ST 2016 wk

- 36 -

3.2.1.1.1 Access Control Functions and Matrices

Example
S = {s1...sn }
O = {o1...om }
A = {read,write}
2A =

{{ },{read },{write},{read,write}}

f (s1,o2 ,read) = granted

f (s3 ,o3 ,read) = granted

s3

f (s3 ,o3 ,write) = granted

o1

o2
{read }

o3

...

om

{read ,
write }

...
sn

all other f = denied

Systems Security, ST 2016 wk

m
s1
s2

- 37 -

3.2.1.1.1 Access Control Functions and Matrices

Notes
Implementations of ACMs in many
OSes
Databases
Middleware platforms (CORBA, Web Services)
Distributed security architectures (Kerberos)
by 2 security mechanisms:

Access Control Lists (ACLs)

columns of an ACM

Unix, Windows, Mac OS (part of I-Nodes)

Capability Lists
rows of ACMs

Amoeba OS, Kerberos, CORBA

Systems Security, ST 2016 wk

- 38 -

3.2.1.1.1 Access Control Functions and Matrices

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Motivation
An Information Systems Scenario ...
Dr. Brains

Dr. Bones

EPR
PatId

Anamn.

Sympt.

Sister Kathy

Apothecary

Systems Security, ST 2016 wk

CT Lab

Diag

Medic.

Brother Tuck

MR Lab

Diet

Paul Bocuse

Pathology

- 39 -

Nursing

Citchen

Administration

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

... modeled by an ACM

S={Dr.Brains, Dr.Bones, BrotherTuck, PaulBocuse, ...}
O={EP.PatId, EP.Diag, EP.Medic, EP.Nursing, ...}

EPR.PatId

EPR.Diag EPR.Medic EPR.Nursing

Dr.Brains

{r,w }

{r,w }

{r,w }

{r,w }

Dr.Bones

{r }

{r }

{r }

{}

BrotherTuck

{r }

{}

{r,w }

{r }

Paul Bocuse

{r }

{}

{}

{}

...

...

We might do it this way, but

Systems Security, ST 2016 wk

- 40 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Is it possible that in a given protection state

a specific subject ever may obtain a specific permission?

EP.PatId EP.Diag

EP.Medic

Dr. Brains

{r}

{r,w}

{r,w}

{r}

{r,w}

{r,w}

Dr. Bones

{r}

{r}

{r}

{r}

{r}

{r}

BrotherTuck

{r}

{}

{r,w}

{r}

{}
{r,w}

{r,w}

Behavior prediction

Systems Security, ST 2016 wk

- 41 -

proliferation of rights
HRU Safety
3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Goal
Statements about

Dynamic behavior of rights

Complexity of such an analysis

Idea
A security model combining

Lampsons ACMs
for modeling single protection states (snapshots)
Deterministic automata
for modeling runtime changes of protection state

Approach

Snapshot of ACM is state of automaton

Runtime changes of ACM caused by state transitions of automaton

Modeled by automatons transition function

Systems Security, ST 2016 wk

- 42 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Definition HRU Security Model

An HRU model is a deterministic automaton (Q, , , q0)
where
Q = 2S x 2O x M is the state space where
S is a (not necessarily finite) set of subjects,
O is a (not necessarily finite) set of objects,
M = {m| m: 2S x 2O 2R } is a set of ACMs with a finite right set R,

= A x X is a finite set of inputs where

A is a set of operations/actions,
X = (S O)k is a k-dimensional vector of subjects and objects, the
parameters of the actions,

: Q x Q is a state transition function,

q0 Q is the initial state.

Systems Security, ST 2016 wk

- 43 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Interpretation

Each state q =(Sq,Oq,mq) models a systems protection state:

Current subject set Sq S

Current object set Oq O

Current ACM mq M where mq: Sq x Oq 2R

state transitions modeled by based on

The current automaton state

An input from = A x (S O)k

Operations (actions) modifying S (creating/destroying subjects)
creating users, processes
Operations modifying O (creating/destroying objects)
creating files, sockets, Web services etc.
Operations modifying matrix cells
entering/removing rights

is often called the authorization scheme of a model

Systems Security, ST 2016 wk

- 44 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Example
Modeling a simple system with

p users

q files

Rights r(ead) and w(rite)

S={si| 1ip}, O={oi| 1iq}, R={r,w}

Initial state qo =(So,Oo,mo)

Subjects and objects: e.g. 1 user, 4 files

So={s1}, Oo={o1,o2,o3,o4}

m0: e.g. all users have rights r und w for all objects
s So, o Oo: mo(s,o)={r, w}

mo
s1

o1
o2
o3
o4
{r , w } {r , w } {r , w } {r , w }

an HRU model of a real-world system is huge!

Systems Security, ST 2016 wk

- 45 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

State Transitions: Modeling Operations that

Create or destroy subjects (e.g. Unix: fork, exit, kill)

Create or destroy objects (creat, unlink)
Modify access rights (chmod, setuid, su)

Authorization Scheme
: Q x Q

| = A x X (input = action + parameters)

: Q x A x X Q

| X = (S O)k (max. k parameters S O )

: Q x A x (S O)k Q

Systems Security, ST 2016 wk

- 46 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Authorization Scheme
: Q x Q is defined by a set of specifications in the normalized form
(q,,x ) = if

r1 mq x s1 , x o1

...

rm mq x sm , x om

then
p1; ... ; pn
fi
where

q =(Sq,Oq,mq) Q, A, x (Sq Oq)k

r1 ... rm R
xs1 ... xsm Sq, xo1 ... xom Oq where
s1 ... sm, o1 ... om are vector indices of parameters in x, 1 si,oi k
p1 pn HRU primitives, see below

Systems Security, ST 2016 wk

- 47 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Convenient Notation (programming languages style)

(assuming q is obvious)

command ( x ) =
if

r1 mq x s1 , x o1

...
r m mq x s m , x o m

then
p1; ... ; pn
fi

Systems Security, ST 2016 wk

- 48 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

6 HRU Primitives:

enter r into m(xs,xo)

delete r from m(xs,xo)

create subject xs

create object xo

destroy subject xs
destroy object xo with the obvious meanings

Modeling of Unix API operations

(q,(write,s,o)) = ?
(q,(fork,s)) = ?
(q,(chmod+rwx,s,o)) = ?
(q,(creat,s,o)) = ?
Systems Security, ST 2016 wk

- 49 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

 Definition of a models authorization scheme by a set of

partial defs / commands
authorization scheme =
(q,(create,s,o)) = if <condition> then <action> fi
(q,(fork,s)) = if <condition> then <action> fi

or alternatively

authorization scheme =
command create(s,o) = if <condition> then <action> fi
command fork(s,o) = if <condition> then <action> fi

Systems Security, ST 2016 wk

- 50 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Model Making
Steps when Designing an HRU Security Model
1. Model Sets
Subjects, objects, operations, rights
definition of sets S, O, A, R, resulting in
M = {m| m: S x O 2R }
Q = 2S x 2O x M
= A x (S O)k
2. Authorization Scheme
Description of semantics of operations that modify the model state
definition of transition function (using normalized form)
3. Initialization
definition of initial state q0 =(S0, O0, m0)
Systems Security, ST 2016 wk

- 51 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Example: HRU Model for an Open University Scenario

Security
Policy

student

Assignments
Server

student
student

assignment
assignment
assignment
solution

writeAssignment
readSolution

Informal Security Policy: 2 Rules

The sample solution can be accessed only after filing the assignment
rule describes

Condition for readSolution

Impact of writeAssignment

Assignments can be filed only prior to reading the solution

rule describes

Systems Security, ST 2016 wk

Condition for writeAssignment

Impact of readSolution
- 52 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Model Making
1. Sets
Subjects, objects, actions, and rights

Subjects: students, e.g. S={si | i}

Objects: the assignments, e.g. O={oi | i}
Actions:
a) File assignment:
writeAssignment(IN student S, IN assignment O)
b) Read solution:
readSolution(IN student S, OUT solution O)
A={writeAssignment, readSolution}
Rights: to execute these actions
R isomorphic to A, e.g.
R={write, read}

Systems Security, ST 2016 wk

- 53 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

2. Authorization Scheme
Effects of actions A on model state
2.1 writeAssignment
State Change:
The sample solution can be accessed only after filing the assignment
IOW: If the automaton gets some input (writeAssignment,s,o) and the conditions are met,
then it changes to a state where access to the solution is granted to s:

(q,writeAssignment,s,o) ::=
if write m(s,o)
then
enter read into m(s,o)
fi

Systems Security, ST 2016 wk

- 54 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

2.2 readSolution
State Change:
Assignments can be filed only prior to reading the solution
IOW: If the automaton gets some input (readSolution,s,o) and the conditions are met, then
it changes to a state where filing assignments is denied to s:

(q,readSolution,s,o) ::=
if read m(s,o)
then
delete write from m(s,o)
fi

Systems Security, ST 2016 wk

- 55 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

3. Initialization
q0 =(S0, O0, m0); e.g. for a course with 3 students:
S0={s1, s2, s3}
O0={o1, o2, o3}
i,1 i 3: m0(si, oi) = write
Interpretation:

Initially there are 3 students s1...s3

with their assignments o1...o3
Initially each student has the right to file his own homework

Systems Security, ST 2016 wk

- 56 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

The Works
Initial ACM State

m0

o1

s1

write

s2

o2

write

s3

Systems Security, ST 2016 wk

o3

write

- 57 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

The Works
Initial ACM State
ACM State after writeAssignment(s3, o3)

m0

o1

s1

write

s2

o2

write
write

s3

Systems Security, ST 2016 wk

o3

read

- 58 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

The Works
Initial ACM State
ACM State after writeAssignment(s3, o3)
ACM State after readSolution(s3, o3)
m0

o1

s1

write

s2

o2

write

s3

Systems Security, ST 2016 wk

o3

read

- 59 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Example Summary
The Works

The models input is a sequence of actions from A together with their

parameters
The automaton changes its state according to the authorization scheme
and the semantics of the HRU primitives (here just enter and delete)
In the initial state each si may (repeatedly) file an assignment oi

Tricks in this Example

The solution itself is not represented by some particular object osolution

Consequently, the ACM has no column for it
We muggled the right to access the solution into the cell of the
assignment
!: model enhancements

Systems Security, ST 2016 wk

- 60 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Security
Policy

student

Assignments
Server

student

We now have got

assignment
assignment
assignment
solution

student

writeAssignment
readSolution

An application scenario
An informal security policy
1. The sample solution can be accessed only ...
2. Assignments can be filed only ...

A formal security model

(Q=S x O x M, ={writeAssignment, readSolution} x S x O, , q0)

What comes next?

Analysis of security properties

Model implementation

Systems Security, ST 2016 wk

- 61 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Analysis of HRU Access Control Models

Reminder
Dr. Brains

Dr. Bones

EPR
PatId

Anamn.

Sympt.

Sister Kathy

Apothecary

CT Lab

Diag

Medic.

Brother Tuck

MR Lab

Nursing

Diet

Paul Bocuse

Pathology

Citchen

Administration

For a given security model, is it possible that a specific subject ever may
get a specific permission with respect to a specific object?
Systems Security, ST 2016 wk

- 62 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Analysis of Right Proliferation

Given a state mq and an authorization scheme
EP.Ident

EP.Diag

EP.Medic

Dr.Brains

{r}

{r,w}

{r,w}

Dr.Bones

{r}

{r}

{r}

BrotherTuck

{r}

{}

{r,w}

{r}

{r,w}

{r,w}

{r}

{r}

{r}

{r}

{}
{r,w}

{r,w}

the HRU-Safety problem

Systems Security, ST 2016 wk

- 63 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Input Sequences
What is the effect of an input in a given state?

What is the effect of an input sequence in a given state?

the composition *

Let ! a be a sequence of inputs from * , consisting of a single input

{ } ( is the empty input sequence), followed by a sequence
a * . Then, *: Q * Q is defined by

* (q, ) = q
* (q, ! a) = * ( (q, ), a).
Systems Security, ST 2016 wk

- 64 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Definition HRU-Safety
A state q=(Sq,Oq,mq) of a given HRU model is called HRU-safe with
respect to a right r R iff beginning with q there is no sequence of
commands that enters r in a matrix cell where it did not exist in q.

Formally:
q is safe wrt. r

s Sq , o Oq , a * : r mq (s, o ) r mq ' (s, o ) where q' = * (q, a).

Systems Security, ST 2016 wk

- 65 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Safety-Decidability
Theorem 1 (HRU, 1976):
For general HRU models, HRU-Safety is not decidable

Theorem 2 (HRU, 1976):

HRU-Safety is decidable for mono-operational HRU models
Mono-operational HRU model:
Each operation in the authorization scheme has the pattern

q,(a,x ) := if

r1 m x s ,xo
1

...

rm m x s ,xo
m

then
p1; ... ;pn
fi
Systems Security, ST 2016 wk

- 66 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Proof Theorem 2
(Decidability of safety for mono-operational HRU models)
Interesting, because
Insights into the operational principles of HRU models
Demonstrates a method to prove safety properties for a given model

Systems Security, ST 2016 wk

- 67 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Proof Theorem 2, 1/9

Proof Sketch
1. Find an upper bound for the length of all input sequences with different
effects on state Q
If there is one only a finite number of inputs with different effect
2. Test all input sequences whether they violate safety
Test algorithm terminates because

Each input sequence is finite

There is only a finite number of different sequences

safety decidable

Systems Security, ST 2016 wk

- 68 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Proof Theorem 2, 2/9

Let 1, ... , n be some sequence of commands * that violates the safety
of q wrt. r (leaks r to some matrix cell)
Claim
For each such sequence, there is a corresponding finite sequence that
Consists only of enter primitives together with 2 initial create primitives
Still leaks r
In other words:
For each input sequence an equivalent finite input sequence exists
Proof
By constructing these finite input sequences

Systems Security, ST 2016 wk

- 69 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Proof Theorem 2, 3/9

Transformation of ... n into smaller sequences with same effect; 5 steps:
1. Remove all operations from a1an, that contain delete- or destroy primitives.
The sequence still leaks r, because conditions in commands only check for the
existence of rights (and not their absence)

Example
create subject x2
create object x5
enter r1 into m(x2 ,x5)
enter r2 into m(x2 ,x5)
create subject x7
delete r1 from m(x2 ,x5)
destroy subject x2
enter r1 into m(x7 ,x5)
...

Systems Security, ST 2016 wk

create subject x2
create object x5
enter r1 into m(x2 ,x5)
enter r2 into m(x2 ,x5)
create subject x7
delete r1 from m(x2 ,x5)
destroy subject x2
enter r1 into m(x7 ,x5)
...

- 70 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Proof Theorem 2, 4/9

2. Add an initial create subject sinit operation at the begin of the sequence. This
changes nothing, because the sequence does not contain any reference to sinit

Example
create subject x2
create object x5
enter r1 into m(x2 ,x5)
enter r2 into m(x2 ,x5)
create subject x7
delete r1 from m(x2 ,x5)
destroy subject x2
enter r1 into m(x7 ,x5)
...

Systems Security, ST 2016 wk

create subject sinit

create subject x2
create object x5
enter r1 into m(x2 ,x5)
enter r2 into m(x2 ,x5)
create subject x7
delete r1 from m(x2 ,x5)
destroy subject x2
enter r1 into m(x7 ,x5)
...

- 71 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Proof Theorem 2, 5/9

3. Remove the last create subject operation in the sequence and substitute each
following reference to this subject by a reference to sinit
Repeat until all create subject operations are removed (apart from the initial
create subject sinit operation)

Example
create subject sinit
create subject x2
create object x5
enter r1 into m(x2 ,x5)
enter r2 into m(x2 ,x5)
create subject x7
delete r1 from m(x2 ,x5)
destroy subject x2
enter r1 into m(x7 ,x5)
...

Systems Security, ST 2016 wk

create subject sinit

create subject x2
create object x5
enter r1 into m(x2 ,x5)
enter r2 into m(x2 ,x5)
create subject x7
delete r1 from m(x2 ,x5)
destroy subject x2
enter r1 into m(sinit ,x5)
...

- 72 -

create subject sinit

create subject x2
create object x5
enter r1 into m(sinit ,x5)
enter r2 into m(sinit ,x5)
create subject x7
delete r1 from m(sinit ,x5)
destroy subject x2
enter r1 into m(sinit ,x5)
...

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Proof Theorem 2, 6/9

Note
After step 3,

Apart from sinit, the sequence no longer creates any subjects

All rights of the formerly created subjects accumulate in sinit

The sequence is more finite

Systems Security, ST 2016 wk

- 73 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Proof Theorem 2, 7/9

4. Same as steps 2 and 3 for objects

Example
create subject sinit
create subject x2
create object x5
enter r1 into m(sinit ,x5)
enter r2 into m(sinit ,x5)
create subject x7
delete r1 from m(sinit ,x5)
destroy subject x2
enter r1 into m(sinit ,x5)
...

Systems Security, ST 2016 wk

create subject sinit

create object oinit
create subject x2
create object x5
enter r1 into m(sinit , oinit)
enter r2 into m(sinit , oinit)
create subject x7
delete r1 from m(sinit ,x5)
destroy subject x2
enter r1 into m(sinit , oinit)
...
- 74 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Proof Theorem 2, 8/9

5. Remove all redundant enter primitives that enter a right in a cell that is already
present

Example
create subject sinit
create object oinit
create subject x2
create object x5
enter r1 into m(sinit , oinit)
enter r2 into m(sinit , oinit)
create subject x7
delete r1 from m(sinit ,x5)
destroy subject x2
enter r1 into m(sinit , oinit)
...
Systems Security, ST 2016 wk

create subject sinit

create object oinit
create subject x2
create object x5
enter r1 into m(sinit , oinit)
enter r2 into m(sinit , oinit)
create subject x7
delete r1 from m(sinit ,x5)
destroy subject x2
enter r1 into m(sinit , oinit)
...
- 75 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Proof Theorem 2, 9/9

This sequence still leaks r, but its length it at most
(|Sq|+1) (|Oq|+1) |R| + 2 ,
because
Each enter primitive Operation now enters a new right into a cell
The number of cells is = (|Sq|+1) (|Oq|+1)
q.e.d.
Proof Theorem 1:
(Non-decidability of safety for general HRU models)

Sketch
Computational power of general HRU model equivalent to Turing
machine

Safety problem equivalent to halting problem

w.y.h.t.b.

Systems Security, ST 2016 wk

- 76 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Assessment of Theorems
Results show Dilemma

(General) HRU models

Have strong expressiveness

broad spectrum of access control models
Are weak wrt. analysis
tools to analyze safety properties difficult to design

Mono-operational HRU models

Have weak expressiveness

to the point of being useless (see modeling of Unix creat-function: can
only create empty ACM columns)
Are strong wrt. analysis
safety decidable, automated tools

Consequences

Restricted calculus fragments

Heuristic analysis methods

Systems Security, ST 2016 wk

- 77 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Restricted Domain-specific Calculus Fragments

Static HRU models: no create operations in authorization scheme

Safety decidable, analysis NP-complete

Application domain: (static) real-time systems, BLP-like models (see below)

Monotonous mono-conditional HRU models

Monotonous: no delete or destroy operations
Mono-conditional: condition parts of authorization scheme contain at most one
condition

Application domain
Archiving systems (documents never are deleted)
MLS systems with static classification function (see below)
Scant practical relevance: rights can never be revoked

Monotonous bi-conditional HRU models

Sorry, safety not decidable

Systems Security, ST 2016 wk

- 78 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Finite subject set

Safety decidable, but huge computational complexity

HRU + restricted authorization scheme: e.g. Take-Grant model

Tailored to OS access control models

Safety decidable in linear (!) time

HRU + strong typing: Typed Access Matrix Model (TAM, see below)

Safety decidable in polynomial time for ternary and acyclic subclass

Pretty high expressiveness

Systems Security, ST 2016 wk

- 79 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Heuristic Analysis Methods

Problem of Restricted Calculus Fragments

Often too weak for modeling real-world scenarios

Problem of General HRU Calculus

Safety not decidable

Exploration of state space by model simulation

State transitions triggered by inputs

Input sequence generated by heuristics

Systems Security, ST 2016 wk

- 80 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Why Heuristics?

Number of states reachable from q?

q= (q,e), e mit = A x (S O)k, e=(,x), A, x (S O)k

|A| |S O|k
Example: A small file server
(AS with 10 actions, 1.000.000 files, actions max. 5 parameters)

10 (106)5 = 1031 follow-up states for q (step 1)

Step 2: Number of states reachable from q 1062

...

problem way too complex to simulate completely

heuristic-based simulation

Systems Security, ST 2016 wk

- 81 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Heuristics

The art of solving problems with limited knowledge and limited time
Term often used as synonym for heuristic methods
General way of solving a problem
To find solution that is hoped to be close to the best possible answer
By means of educated guess, common sense, rule of thumb

Systems Security, ST 2016 wk

- 82 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

For the HRU Safety property analysis, Heuristics

Exploit semi-decidability of the HRU-Safety problem

Search for right leaks
Assess a state sequences probability to leak a right
Accordingly channel the growth of state space (tree with root q)
q

q
qi
q i

Systems Security, ST 2016 wk

- 83 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Heuristic-based Decisions
Simulation step: (qi,e), e=(,x)
choice of state qi
choice of action
choice of parameters x
q

q
qi
(qi,e)
q i

Systems Security, ST 2016 wk

- 84 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Example: The DepSearch Heuristic

Goal
To prove that a given state q is not safe wrt. a given right r
Approach
To find an input sequence ((command, parameter)-tuples) that leaks r
Idea
Step-by-step establishment of necessary conditions for entering r in a
matrix cell

Systems Security, ST 2016 wk

- 85 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Step 1: find all commands in that enter r

(one of these MUST be executed as the final simulation step
necessary condition)
Step 2: for each such command, find the set of preconditions (rights)
(which MUST be satisfied in order for this command to be executed)
Step 3..n: for each right ri in these sets, find all commands that enter ri
continue with Step 2 and 3 until all preconditions are satisfied by q
this results in a ...

Systems Security, ST 2016 wk

- 86 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Command Dependency Graph

c5 enters r, requires some right set R5

c4 establishes rights in R5, but requires some right set R4
rights in R4 are established by c2 and c3
...
c1
c2
c3
c4
c5

input sequences for the model simulation are paths in the CDG

Systems Security, ST 2016 wk

- 87 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Messages

There are many different heuristics, making different assumptions

Bottom line: randomized
Sophisticated: Exploiting different model properties
The more a given model
Satisfies the specific assumptions
Exhibits exploitable model properties
, the more successful are heuristic-based model analysis approaches

Systems Security, ST 2016 wk

- 88 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Summary HRU Models

Goal

Analysis of right proliferation

Computability of such analyses

Method

Combination of ACMs and deterministic automata

Results
Safety not decidable in general
HRU model family, domain-specific calculus fragments
heuristic based analysis methods

Systems Security, ST 2016 wk

- 89 -

3.2.1.1.2 Harrison, Ruzzo, Ullman Model

3.2.1.1.3 The Typed Access Matrix (TAM) Model

R. Sandhu 1992

Goals

Access control model, HRU family

direct mapping to standard security mechanisms: ACLs (OSs),
tables (DBMSs)
implementability
Better analytical properties compared to HRU models
decidable safety properties

Method

Adopted from HRU: subjects, objects, automaton

Plus exploiting the merits of type systems known from programming
languages
restrictions inflicted by types

Systems Security, ST 2016 wk

- 90 -

3.2.1.1.3 The Typed Access Matrix Model

How it works:

Foundation of a TAM model is an HRU model (Q, , , q0) where

Q = 2 S x 2O x M
Object set O
However, S O; objects in O-S: pure objects
m

s1

s2 o1 o2 o3

s1
s2

Each o O is assigned a type from a type set T by t: O T

(consequently, each subject also is typed)

An HRU model is a special case of a TAM model:

T = {subject, object}

s S: t(s)=subject, o O-S: t(o)=object

Systems Security, ST 2016 wk

- 91 -

3.2.1.1.3 The Typed Access Matrix Model

Definition TAM Security Model

A TAM security model is a tuple (T, Q, , , q0) where
T is a (static) set of types,
Q = 2S x 2O x TYPE x M is the state space where
O is a (not necessarily finite) set of objects,
S O is a (not necessarily finite) set of subjects,
TYPE = {t| t: S O T } is the set of all type functions,
M = {m| m: S x O 2R } is a set of ACMs with a finite right set R,

= A x X is a finite set of inputs where

A is a set of operations/actions,
X = Ok is a k-dimensional vector of subjects and objects, the
parameters of the actions,

: Q x Q is a state transition function, and

q0 Q is the initial state.
Systems Security, ST 2016 wk

- 92 -

3.2.1.1.3 The Typed Access Matrix Model

The Authorization Scheme

: Q x Q is defined by a set of expressions in the pattern
(q,,x ) = if

r1 mq x s1 , x o1

...

rm mq x sm , x om

then
p1; ... ; pn
fi

where

q =(Sq,Oq,mq) Q, A

x(Sq Oq)k
r1 ... rm R

xsi Sq, xoi Oq-Sq where

s1 ... sm, o1 ... om are vector indices of the parameters in x, 1 si,oi k

p1 pn TAM primitive operations, see below

Systems Security, ST 2016 wk

x {(o, to)| o Oq, to T, t(o)=to}k

- 93 -

3.2.1.1.3 The Typed Access Matrix Model

Implicit Addendum to Authorization Scheme: Type Checking

(q,,x ) := if

t ( x1 ) = t x1

...

t ( x k ) = t xk

r1 mq x s1 , x o1

...

rm mq x sm , x om

then
p1; ... ; pn
fi

Systems Security, ST 2016 wk

- 94 -

3.2.1.1.3 The Typed Access Matrix Model

Convenient Style (programming languages)

command ( x1 : t1, x 2 : t 2 ,..., x k : t k )
if

r1 mq (x s1 , x o1 )

...

rm mq (x sm , x om )
then
p1; ... ; pn
fi
where

q Q implicit

, r1 ... rm, s1 ... sm, o1 ... om as before

the p1 pn ...

Systems Security, ST 2016 wk

- 95 -

3.2.1.1.3 The Typed Access Matrix Model

TAM Primitives

enter r into m(xs,xo)

delete r from m(xs,xo)

create subject xs of type ts

create object xo of type to

destroy subject xs

destroy object xo

(with their obvious semantics)

Note:
Because S and O are dynamic, t is in so far dynamic, too

Systems Security, ST 2016 wk

- 96 -

3.2.1.1.3 The Typed Access Matrix Model

The Works
Example: The ORCON Policy
(ORCON = ORiginator CONtrolled access rights)

Illustrates expressive power and usefulness of TAM

Problem is sub-problem in larger policy
Information flow confinement (tricky in HRU)

Systems Security, ST 2016 wk

- 97 -

3.2.1.1.3 The Typed Access Matrix Model

The Problem

Creator/owner of document permanently retains control

Neither direct nor indirect (by copying) right proliferation
owns

R&D

ProjectX
Files

Ann

grants
read right

Bob
grants
read right
no information flow

Sales

Sales
Flyer

Chris
may not forward information
obtained by that right

Systems Security, ST 2016 wk

- 98 -

3.2.1.1.3 The Typed Access Matrix Model

The TAM Solution

Basic Idea
A confined subject type that never may do anything but read

Model Sets

Rights R ={own, read, write, cread, parent}

Subjects S={Ann, Bob, Chris}
Objects O=S {ProjectXFile}
Types T ={s, cs, co} (= regular subject, confined sub/object) where
t(Ann) = s
t(Bob) = s
t(Chris) = cs
t(ProjectXFile) = co

Systems Security, ST 2016 wk

- 99 -

3.2.1.1.3 The Typed Access Matrix Model

owns

R&D

The Works

ProjectX
Files

Sales

m
Ann: s

Ann: s

Bob: s

ProjectXFile: co

Ann

Bob

no information flow
Sales
Flyer

Chris

own, read, write

Bob: s

Step 1:
Ann creates ORCON object ProjectXFile
(protection scheme command createOrconObject, see below)

Systems Security, ST 2016 wk

- 100 -

3.2.1.1.3 The Typed Access Matrix Model

owns

R&D

ProjectX
Files

Sales

Ann: s

Bob: s

ProjectXFile: co

Ann: s

own, read, write

Bob: s

cread

Ann

Bob

no information flow
Sales
Flyer

Chris

Step 2:
Ann grants confined read right for ProjectXFiles to Bob
(protection scheme command grantCRead)

Systems Security, ST 2016 wk

- 101 -

3.2.1.1.3 The Typed Access Matrix Model

owns

R&D

ProjectX
Files

Sales

Ann: s

Bob: s

ProjectXFile: co

Ann: s

own, read, write

Bob: s

cread

Chris: cs

read

Chris: cs

Ann

Bob

no information flow
Sales
Flyer

Chris

parent

Step 3:
Bob uses cread right to create confined subject Chris with permission to
read ProjectXFiles
(protection scheme command useCRead)

Systems Security, ST 2016 wk

- 102 -

3.2.1.1.3 The Typed Access Matrix Model

The Protection Scheme

(a) command createOrconObject(s1: s, o: co)
create object o of type co;
enter own in m(s1,o);
enter read in m(s1,o);
enter write in m(s1,o);
end
(b) command grantCRead(s1: s, s2: s, o: co)
if ownm(s1,o) then
enter cread in m(s2,o);
fi
end
Systems Security, ST 2016 wk

- 103 -

3.2.1.1.3 The Typed Access Matrix Model

(c) command useCRead(s2: s, o: co, s3: cs)

if creadm(s2,o) then
create subject s3 of type cs;
enter read in m(s3,o);
enter parent in m(s2,s3);
fi
end
Commands (a)-(c)
Authorize steps 1-3
Are monotonic
Commands (d)-(g) (below)
Are examples for right revocation (ORCON)
Are non-monotonic; consequences see below
Systems Security, ST 2016 wk

- 104 -

3.2.1.1.3 The Typed Access Matrix Model

(d) command revokeCRead(s1: s, s2: s, o: co)

if ownm(s1,o) then
delete cread from m(s2,o);
fi
end

(Ann revokes cread from Bob)

(e) command destroyOrconObject(s1: s, o: co)

(Ann destroys CO ProjectXFile)

if ownm(s1,o) then
destroy object o;
fi
end

owns

R&D

Ann
ProjectX
Files
Bob

Sales

no information flow
Sales
Flyer

Systems Security, ST 2016 wk

- 105 -

Chris

3.2.1.1.3 The Typed Access Matrix Model

(f) command revokeRead(s1: s, s3: cs, o: co)

if ownm(s1,o) readm(s3,o) then
destroy subject s3;
fi
end

(Ann destroys CS Chris)

(g) command finishOrconRead(s2: s, s3: cs)

(Bob destroys CS Chris)

if parentm(s2,s3) then
destroy subject s3;
fi
end

owns

R&D

Ann
ProjectX
Files
Bob

Sales

no information flow
Sales
Flyer

Systems Security, ST 2016 wk

- 106 -

Chris

3.2.1.1.3 The Typed Access Matrix Model

What do we gain? Results

TAM models
safety still not decidable (obviously)

MTAM (monotonous TAM; AS without delete and destroy operations)

Safety not decidable from bi-conditional upwards

Acyclic (see below) MTAM models

Safety decidable, but NP-hard

Ternary acyclic MTAM models (max. 3 parameters)

same computational power as acyclic MTAM
Safety decidable, in polynomial time

Systems Security, ST 2016 wk

- 107 -

3.2.1.1.3 The Typed Access Matrix Model

Characterization of Acyclic TAM Models

Type Creation Graphs:
Relation canCreate:
(u,v) canCreate subjects of type u can create objects of type v
ti {t1tk} is called child type in A
ti is type of a subject or object created in

(else ti is called parent type)

Type Creation Graph: reflects parent/child relations

Vertices: T

An edge (t,u) T x T exists A: t is parent, u is child

A TAM model is called acyclic its type creation graph is acyclic

Systems Security, ST 2016 wk

- 108 -

3.2.1.1.3 The Typed Access Matrix Model

Expressive Power

MTAM: inherits expressive power from monotonic HRU

cannot model

Transfer of rights (enter r into ; delete r from )

Countdown rights (r can be used only a fixed number of times)

ORCON example

Non-monotonic commands (d)-(g) can be ignored for safety analysis

because they
1. just remove rights and
2. are reversible; e.g.
(d) can be undone by (b)
(g) can be compensated by (c) where the new subject takes role of
destroyed one

Systems Security, ST 2016 wk

- 109 -

3.2.1.1.3 The Typed Access Matrix Model

Professional TAM Model Applications

Types in SELinux security policies reflect domain association:
Processes in this domain are allowed to ... processes have same type
Scalability

Systems Security, ST 2016 wk

- 110 -

3.2.1.1.3 The Typed Access Matrix Model

IBAC Summary
We Now Can
Model identity-based AC policies
Analyze them wrt. basic security properties (right proliferation)
Infer implementations
in order to minimize
Specification errors
Implementation errors

Approach

Objectification by precise calculus

Prediction and proof of properties
Derivation of implementations

Systems Security, ST 2016 wk

- 111 -

3.2.1.1 Identity Based Models

Model Spectrum

Static models:

Access control functions

f : S x O x A {granted, denied}

Access control matrices:

m: S x O 2A

analysis: hidden information flow, informational equivalence classes

implementation: access control lists (Unix, Windows, DBMSs)

Dynamic models: HRU calculus, restricted calculus fragments

ACM
Plus automaton
Plus type system

analysis of dynamic behavior: HRU safety

Major problem: decidability
restricted calculus fragments (monotonous, static, ..., typed models)
heuristic analysis algorithms

Systems Security, ST 2016 wk

- 112 -

3.2.1.1 Identity Based Models

However

IBAC models indeed are fundamental

But not necessarily universal

Mobile devices (smartphones): single user

fundamental model paradigm inadequate

Large information systems: too many users

scalability
Access decisions just based on subjects, objects, operations
small und inflexible

Systems Security, ST 2016 wk

- 113 -

3.2.1.1 Identity Based Models

3.2.1.2 Role-based Access Control Models

Problems of IBAC Models

Scalability wrt. number of entities

Individual rules for each subject and object

Ann is allowed to read projectXFiles
above file server example: >106 access control rules
Large and complex models

Level of abstraction

System-, not problem-oriented (processes and files)

Goals of Role-based Access Control

Scalability
Manageability
Application-oriented: roles functions in organizations

Systems Security, ST 2016 wk

- 114 -

3.2.1.2 Role-based Access Control Models

Application Domains

Public health care systems

roles: patient, physician, therapist, pharmacist, insurer, legislator ...

Financial organizations
roles: client, consultant, analyst, product developer ...

Operating systems
roles: SysAdmin, WebAdmin, UserAdmin, User ...

Systems Security, ST 2016 wk

- 115 -

3.2.1.2 Role-based Access Control Models

Idea

Models include role abstractions

Role engineering based on organizational structure
Responsibilities
Competences
Access control rules based on roles
All ward physicians are allowed to read EPRs

Dr. Brains
Dr. Bones

read EPRs

Ward
Phys.

Nurse Kathy

read medications

Nurse

Brother Tuck

write check records

user-to-role relation

Systems Security, ST 2016 wk

write EPRs

role-to-right relation

- 116 -

3.2.1.2 Role-based Access Control Models

IBACRBAC
IBAC

Subjects, objects, rights for executing operations

Access rules based on identifications of subjects and objects

O
S

Subject

Object

Operation
Systems Security, ST 2016 wk

- 117 -

3.2.1.2 Role-based Access Control Models

IBACRBAC
RBAC

Users, roles, rights for executing operations

Access rules based on roles of users; assign
Users to roles
Roles to rights

User

Role

Right

Subject

Object

Operation
Systems Security, ST 2016 wk

- 118 -

3.2.1.2 Role-based Access Control Models

Definition RBAC0 Security Model

An RBAC0 model is a tuple (U, R, P, S, UA, PA, user, roles)
where
U is a (not necessarily finite) set of users,
R is a set of roles,
P = 2(O x OP) is a finite set of rights (permissions) where
O is a set of objects,
OP is a set of operations,

S is a set of sessions,
UA U x R is a users-to-roles relation,
PA P x R is a permissions-to-roles relation,
user: S U is a function mapping sessions to users,
roles: S 2R is a function mapping sessions to sets of roles where

s S, r R: r roles(s) (user(s),r) UA

Systems Security, ST 2016 wk

- 119 -

3.2.1.2 Role-based Access Control Models

Interpretation

Users U model people, or (software-)agents (e.g. processes)

Roles R model tasks, functions, or areas of responsibility in organizations
Permissions P: read documents, transfer money, ...

Users

Systems Security, ST 2016 wk

Roles

- 120 -

Permissions

3.2.1.2 Role-based Access Control Models

user-to-role relation UA U x R describes the roles available to users

(static)
Bob may act as project leader, as department head, ...
permission-to-role relation PA P x R describes the permissions
associated to roles (static)
Each project leader is allowed to ...

Users

Systems Security, ST 2016 wk

UA

Roles

- 121 -

PA

Permissions

3.2.1.2 Role-based Access Control Models

Sessions reflect dynamic role assignments: a session s S is created

when a user logs in
session-to-user assignment user: S U associates a session with a
user
session-to-roles assignment roles: S 2R associates a session with
a set of roles (that are active in a session)

Users

user

Subject

UA

Session

Roles

PA

Permissions

roles

static
dynamic

Object

Operation
Systems Security, ST 2016 wk

- 122 -

3.2.1.2 Role-based Access Control Models

Access Control Function f

With OP, set of operations,
f : U O OP {true,false}
true | r R,s S : u = user (s),r roles(s), (o,op),r PA
f (u,o,op) !
false | else

A role r exists that contains the permission to execute op on o, and this

role is currently assigned to a session s that is active for user u
PA
Role

Permission

Session

Role

Permission

Session

Role

roles
user
User

Permission

Session
Systems Security, ST 2016 wk

- 123 -

3.2.1.2 Role-based Access Control Models

RBAC Family
Sandhu 1996

RBAC0

RBAC1

RBAC2
RBAC3

RBAC0: basic model

RBAC1: RBAC0 plus role hierarchies
RBAC2: RBAC0 plus constraints
RBAC3: consolidation; RBAC0 plus RBAC1 plus RBAC2

Systems Security, ST 2016 wk

- 124 -

3.2.1.2 Role-based Access Control Models

RBAC1: Role Hierarchies

Observation

Roles within an organization often overlap

users in different roles share permissions
Example:
Permissions of project member are part of permissions of project manager

role definitions in RBAC0 contain redundancy

Permissions must be defined in each such role

Goal
To eliminate redundancy

Approach
Role hierarchy: Permission inheritance between roles

Systems Security, ST 2016 wk

- 125 -

3.2.1.2 Role-based Access Control Models

Examples
Nursing staff

Project staff

Tester

Apprentice physician

Programmer

Physician

Project manager

Ward physician Ward physician

surgery
ENT

Head physician
Systems Security, ST 2016 wk

- 126 -

3.2.1.2 Role-based Access Control Models

Hierarchy Modeling:

Lattices and Dominance Relations

Lattice: a tuple (C, )
Class set C

Partial ordering

Properties

Reflexive:
Anti-symmetric:
Transitive:

c C: c c
c,d C: c d and d c c = d
c,d,e C: c d and d e c e

Examples
(, )

(2X, ), X arbitrary set

Systems Security, ST 2016 wk

- 127 -

3.2.1.2 Role-based Access Control Models

Role Hierarchy Modeling

Class set R (roles)

Hierarchy relation:
r1 r2 r1 passes permissions to r2

Interpretation

Reflexivity: a role inherits its own permissions

r R: r r

Anti-symmetry: roles that mutually inherit permissions are identical:

r1, r2 R: r1 r2 and r2 r1 r1 = r2

Transitivity:
r1, r2, r3 R: r1 r2 and r2 r3 r1 r3

Systems Security, ST 2016 wk

- 128 -

3.2.1.2 Role-based Access Control Models

Example
Project staff
passes
permissions

Tester

Programmer
passes
permissions

Project staff Tester

Project staff Programmer
Tester Project manager
Programmer Project manager

Project manager

Systems Security, ST 2016 wk

- 129 -

3.2.1.2 Role-based Access Control Models

Definition RBAC1 Security Model

A RBAC1 model is a tuple (U, R, P, S, UA, PA, user, roles, RH)
where

U, R, P, S, UA, PA, user same as RBAC0,

RH R x R is a partial order over R for describing a role hierarchy
where (r1, r2)RH r1 r2 (so (R, ) is a lattice)

roles is such that additionally to RBAC0 holds:

s S, r1,r2 R: r2 roles(s), r1r2 r1 roles(s)

Each role from which a role in roles(s) inherits permissions and that is
open for a user is also in roles(s)

Systems Security, ST 2016 wk

- 130 -

3.2.1.2 Role-based Access Control Models

Interpretation
Role

User

user

Session

Role

roles
Role

Systems Security, ST 2016 wk

- 131 -

Role

Role

3.2.1.2 Role-based Access Control Models

RBAC2: Constraints
Observation

People may not assume certain roles at the same time

mission- and security critical
Example: purchasing manager and head of internal controlling
separation of duty
Avoid risks
Find errors (second set of eyes)

Goal

Representation of constraints

Approach

Attach conditions to model components

Systems Security, ST 2016 wk

- 132 -

3.2.1.2 Role-based Access Control Models

Examples for Constraints

Separation of duty
e.g. mutual exclusion of roles
Quantitative restrictions
e.g. to avoid accumulation of offices
Maximum number of users per role (e.g. head of department)
Maximum number of permissions per role (e.g. critical permissions)
Factual restrictions

Permission may only be assigned to role if another permission is already

granted (permission to delegate X only if X is permitted)

Model
(U, R, P, S, UA, PA, user, roles, RE) where RE models restrictions on other
model components such as UA, PA, user, or roles
Systems Security, ST 2016 wk

- 133 -

3.2.1.2 Role-based Access Control Models

RBAC Summary
Pros

Scalability
Application-oriented model abstractions
Standardized
tool support (e.g. for role engineering)

Cons

OS support weak (few systems, e.g. Trusted BSD, SELinux)

application-level integration (e.g. in information systems, DBMS)
Weak analytical power
see HRU models: safety properties
next step: combine RBAC models with HRU calculus
BSc/MSc theses (DRBAC0-3)

Systems Security, ST 2016 wk

- 134 -

3.2.1.2 Role-based Access Control Models