ch3 system security

8/16/2019 Ch3 System Security

1/134

Systems Security, ST 2016 © wk - 1 -

Winfried E. KühnhauserCSIIlmenau Technical Universitywww.tu-ilmenau.de

Systems SecurityChapter 3: Security Policies and Models

Winfried E. Kühnhauser Summer Term 2016


2/134


Roadmap

3 Security Policies and Models

Security Mechanisms

Security Policies

Modeling and Specification

Security Architectures

Security Requirements


3/134


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



4/134


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



5/134


A CS Scenario: Hospital Information Systems

Excerpt from an information flow policy

EPR Anamn. Sympt. Diag Medic. Nursing DietPatId

Brother TuckSister Kathy Paul Bocuse

Dr. Brains

Apothecary CT Lab MR Lab Pathology Citchen Administration

Dr. Bones

Complete IF-Graph:>> 10.000 legal (and necessary!) information flows> 100 obvious conflicts (without transitiveness)> 100 forgotten information flows ! ad-hoc-approaches fail



6/134


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



7/134


8/134Systems Security, ST 2016 © wk - 8 -

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 "

!

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

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




Example 2

Excerpt from a CSCW Policy

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

Internet




Implementation of Security Policies

Alternatives Integrated in system software

! Operating Systems! Data Base Systems! Middleware platforms

Integrated in application systems




Policy-controlled Operating Systems

Application

Process

Application

Process

Application

Process

Application

Process

OSFile System Policy Server

S= {s 1,s 2 ,s 3}, O={o 1,o2 ,so 3}...command read (s ,o)

if read ! m(s,o )enter (s ,o) in h;

" o i ! O, (o i ,o)! C : delete read from m(s ,oi );" o i ! O, o i ! o: delete write in m(s ,o i );

end ifend

...




Components Security Server: Policy‘s runtime environment in kernel‘s protection domain

" Interceptors: complete interaction control

SocketsFilesystemsProcess

Management

Application Process Application Process Application Process ApplicationLayer

OSLayer

System-wide Resource Management

ProcessingResources

MemoryResources

CommunicationResources

OS Interface ( Application Programmer‘s Interface ( API ))

OSServices

. . . SecurityServerPolicy

ProcessManagement

Filesystems Sockets

E.g. the SELinux Security Architecture




Policy Installation in SELinux

System-wide Resource Management

ProcessingResources

MemoryResources

CommunicationResources

OS Interface ( Application Programmer‘s Interface (API))

OSServices Sockets

Dateisysteme . . .Prozesse Sec. ServerProcessMgmtFilesystems Sockets

1 allow sysadm_t insmod_exec_t:file x_file_perms; 2 allow sysadm_t insmod_t:process transition; 3 allow insmod_t insmod_exec_t:process {entrypoint execute};

4 allow insmod_t sysadm_t:fd inherit_fd_perms; 5 allow insmod_t sysadm_t:process sigchld;

Security Policy BinaryPolicy Compiler



14/134



Policy-controlled ApplicationsEmbedded Policy

S= {s 1,s 2 ,s 3}, O={o 1,o 2 ,so 3}...command read (s ,o )


" oi ! O, (o i ,o)! C : delete read from m(s ,oi );" oi ! O, o i ! o: delete write in m(s ,oi );

end ifend

...

Application

Process

Application

Process

Application

Process

OS




Application

Process

Application

Process

Application

Process

OS

Policy-controlled Applications Application-level Policy Servers

Policy ServerS= {s 1,s 2 ,s 3}, O={o 1,o2 ,so 3}...command read (s ,o)


" o i ! O, (o i ,o)! C : delete read from m(s ,oi );" o i ! O, o i ! o: delete write in m(s ,o i );

end ifend

...



17/134



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

in flow

Handlerm

Handler2

Handler1• • •

AxisEngine

instanciates

out flow

TransportSender

Handler1

Handler2

Handlern• • •

AxisEngine

instanciates

Client

S t u b

SOAP Reply

CoordinatorOutInAxisOperation

instanciates

SOAP Request(by HTTP, JMS ...)

MC req MC resp

MC resp




out flow

Handlerm

Handler2

Handler1• • •

AxisEngine

in flow

Handler1

Handler2

Handlern• • •

AxisEngine

MC req

MC resp

SOAP Reply

SOAP Request

A x

i s S e r v

l e t

H T T P / J M S

T r a n s p o r

t U t i l i t i e s

Transport

Sender

W e b

S e r v i c e

MessageReceiver

MC req

MC resp




Messages 3.1

The Part of Security Policies


RequirementsEngineering

SecurityRequirements

SecurityPolicy

PolicyEngineering

ModelEngineering

ArchitectureEngineering

SecurityModel

Security Architecture



3.2 Security Models

3.2 Security Models



The Linda-Test

! subjective statements colored by individual experience

3.2 Security Models

Linda is a bright and active student, ... , lobbying in the student’s council,... , participating in demonstrations, ...

o Linda works as a bank clerk

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

groupo . . .



Goal of Formal Security ModelsImpartial, 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 ...”

3.2 Security Models



Methods

Abstraction from (usually too complex) reality: get rid of insignificantdetails! computability and computation complexity

Getting precise : formal description of essentials ! model analysis and implementation

3.2 Security Models



Definition A security model is a precise, in general formal representation of asecurity policy.

The ambition is to analyze the behavior of a security policy and to be ableto prove essential properties

3.2 Security Models


26/134


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

3.2 Security Models


27/134


3.2.1 Access Control Models

Formal Representations of Permissions to Execute Operations

on Objects Reading files Issuing payments Executing Web services



28/134


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



29/134


Discretionary Access Control (DAC)Individual users specify access rules to objects within their area ofresponsibility

Example Access control in many OSes (e.g. Unix, Windows)

ConsequenceIndividual users

Enjoy freedom wrt. to granting access rights

Are obliged to maintain conformity to organization’s security policy! competence problem! responsibility problem! malware problem



30/134


Mandatory Access control (MAC)System-wide rules apply that cannot be sidestepped by individual users

ExampleSee Hospital Information System above

Consequence Limited individual freedom In charge of security policy:

! Clearly identified instance! Competent! Responsible

No responsibility of individuals



31/134


In Reality we frequently seeHybrid models with discretionary and mandatory components; e.g.

Discretionary: within a project, members individually define thepermissions wrt. documents

Mandatory: only documents authorized by the security policy can beaccessed from outside the project’s security domain



32/134


3.2.1.1 Identity Based Access Control Models (IBAC)

Basic ParadigmThere are" Subjects : active and identifiable entities that execute" Operations on" Objects

" Access rights! Control execution of operations! Refer to identity of subjects and objects

3.2.1.1 Identity Based Models

Operation " process reading a file" Web server accessing html page" client transfers money from Bank account

ObjectSubject


33/134


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 }



34/134


ExampleModeling access rights for Web Services

Model: ( S ,O, A,f ) whereS = {Bosch, VDO, Siemens } as set of subjectsO = {deliveryTime_WS } as set of objects

A = {see, execute, update } as set of operationsf : S x O x A ! {granted, denied } as access control function where e.g.

f (Bosch, deliveryTime_WS, see ) = grantedf (Bosch, deliveryTime_WS, execute ) = granted

f (Bosch, deliveryTime_WS, update ) = deniedf (VDO, ...



35/134


Example Access control model of the Unix OS (extremely simplified)

Model: ( S ,O, A,f ) whereS : set of usersO: set of system objects (files, directories, sockets, " )

A: set of system callsf : 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 OKelse {

g=caller.egid;if (g==o.inode.group and a_mode in o.inode.groupRWX) then

return OKelse …


36/134


Access Control Matrices

Access Control Functions in Practice

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

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

! Lampson’s access control matrix (ACM): a tuple ( S , O, m)



37/134


38/134


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



39/134


3.2.1.1.2 Harrison, Ruzzo, Ullman Model

Motivation

An Information Systems Scenario ...




Dr. Brains


Dr. Bones


40/134


... modeled by an ACM

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

We might do it this way, but "

M 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 } {} {} {}

. . .



41/134


42/134


Goal

Statements about Dynamic behavior of rights Complexity of such an analysis

Idea A security model combining

Lampson’s 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 automaton’s transition function$



43/134


Definition HRU Security Model

An HRU model is a deterministic automaton (Q, # , $ , q 0)

whereQ = 2 S 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 : 2 S x 2O ! 2 R } 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.



44/134


Interpretation Each state q =(S q,O q,m q) models a system’s protection state:

! Current subject set S q & S ! Current object set O q & O ! Current ACM m q ! M where m q: S q x Oq ! 2 R

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



45/134


Example

Modeling a simple system with p users q files Rights r(ead) and w(rite)

! S ={si | 1 ' i' p }, O ={o

i | 1 ' i' q}, R ={r ,w }

Initial state qo =(S o,O o,m o) Subjects and objects: e.g. 1 user, 4 files

! S o={s 1}, O o={o1,o2,o3,o4}

m 0: e.g. ”all users have rights ‚ r‘ und ‚ w ‘ for all objects“! " s ! S o, o ! O o: m o(s ,o)={r , w }

!

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

},{},{},{},{14321

w r w r w r w r s

oooomo



46/134


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



47/134


Authorization Scheme $ $ : Q x # ! Q is defined by a set of specifications in the normalized form

where! q =(S q,O q,m q) ! Q, " ! A, x ! (S q % Oq)k ! r 1 ... r m ! R ! x s 1 ... x s m ! S q, x o1 ... x om ! Oq where

s 1 ... s m, o1 ... om are vector indices of parameters in x , 1 ' s i ,o i ' k!

p 1 "

p n HRU primitives, see below

( )

fi

;...;

then

,

...

,if

1

1 11

n

osqm

osq

p p

x x mr

x x mr ,x q,

mm!

"

"!=# $



48/134


Convenient Notation (programming languages style)(assuming q is obvious)

( )

( )

fi;...;

then,

...

,if )(command

1

1 11

n

osqm

osq

p p

x x mr

x x mr

x

mm!

"

"!

=#



49/134


50/134


! Definition of a model‘s authorization scheme $ by a set of

partial defs / commands

authorization scheme =$ (q,(create ,s ,o)) = if then fi$ (q,(fork ,s )) = if then fi! ! !

or alternatively

authorization scheme =command create (s ,o) = if then ficommand fork (s ,o) = if then fi! ! !


M d l M ki


51/134


Model Making

Steps when Designing an HRU Security Model

1. Model SetsSubjects, objects, operations, rights! definition of sets S , O, A, R , resulting in

• M = {m| m : S x O ! 2 R }• Q = 2 S x 2O x M • # = A x (S % O)k

2. Authorization SchemeDescription of semantics of operations that modify the model state! definition of transition function $ (using normalized form)

3. Initialization! definition of initial state q0 =(S 0, O 0, m 0)



52/134

M d l M ki


53/134


Model Making

1. Sets

Subjects, objects, actions, and rights Subjects: students, e.g. S ={s i | i ! ! } Objects: the assignments, e.g. O={o i | 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 }



54/134


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)

thenenter read into m (s ,o)

fi



55/134


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, thenit 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


56/134


3. Initialization

q0 =(S 0, O 0, m 0); e.g. for a course with 3 students:S 0={s 1, s 2, s 3}O0={o1, o2, o3}" i ,1 $ i $ 3: m 0(s i , o i ) = write

Interpretation: Initially there are 3 students s 1... s 3 " with their assignments o1... o3 Initially each student has the right to file his own homework


The Works


57/134


Initial ACM State

The Works


m0

o1

o2

o3

s1

write

s2

write

s3

write


58/134

The Works


59/134


Initial ACM State

ACM State after writeAssignment (s 3, o3) ACM State after readSolution (s 3, o3)

The Works


m0

o1

o2

o3

s1

write

s2

write

s3

read

Example Summary


60/134


Example Summary

The Works The model’s 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 s i may (repeatedly) file an assignment o i

Tricks in this Example The solution itself is not represented by some particular object o solution Consequently, the ACM has no column for it We muggled the right to access the solution into the cell of the

assignment

: model enhancements



61/134


We now have got 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


assignmentassignment

writeAssignmentreadSolution

student

AssignmentsServer

SecurityPolicy

student

student

assignment

solution

Analysis of HRU Access Control Models


62/134


Analysis of HRU Access Control Models

Reminder

”For a given security model, is it possible that a specific subject ever mayget a specific permission with respect to a specific object?“




Dr. Brains


Dr. Bones


63/134


Analysis of Right Proliferation

Given a state m q and an authorization scheme $

! the HRU-Safety problem

{r }$

?

{r,w } {r,w }

{r } {r } {r }

{}{r } {r,w }

Dr.Brains

Dr.Bones

BrotherTuck

EP.Ident EP.Diag EP.Medic

{r } {r,w } {r,w }

{r } {r } {r }

{}{r } {r,w } {r,w }



64/134


{ }bydefinedis : Then, .

sequenceabyfollowedsequence),inputemptytheis( inputsingleaof consisting ,frominputsof sequenceabe Let

***

*

QQa

a

!"#"$

%"$

"

&

' ' (

( !

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 $ *

).),,((),(),(

**

*

aqaq

qq

! " " ! "

# "

=

=

!



65/134


Definition HRU-Safety

A state q= (S q,O q,m q) of a given HRU model is called HRU-safe withrespect to a right r ! R iff beginning with q there is no sequence ofcommands that enters r in a matrix cell where it did not exist in q.

Formally:q is safe wrt. r #

).,(' where),(),(:,, *'* aqqosmr osmr aOoS s qqqq ! ="#"$%%%&


Safety-Decidability


66/134

Systems Security, ST 2016 © wk - 66 - 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

! q, a,x ( )( ) := if r 1 ! m x s 1 , x o 1( ) "

... "

r m

! m x s

m

, x o

m( )

then

p 1; ... ; p nfi

Mono-operational HRU model:Each operation in the authorization scheme has the pattern


67/134


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


Proof Theorem 2 1/9


68/134


Proof Theorem 2, 1/9

Proof Sketch

1. Find an upper bound for the length of all input sequences with different effects on state QIf there is one ( ) only a finite number of inputs with different effect

2. Test all input sequences whether they violate safetyTest algorithm terminates because

! Each input sequence is finite! There is only a finite number of different sequences

( safety decidable




69/134



Let ! 1, ... , ! n be some sequence of commands ! # * that violates the safetyn be some sequence of commands ! # * that violates the safety

of q wrt. r (leaks r to some matrix cell)

ClaimFor 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

ProofBy constructing these finite input sequences !



70/134



71/134



2. Add an initial create subject s init operation at the begin of the sequence. Thischanges nothing, because the sequence does not contain any reference to s init

create subject s init create subject x 2 create object x 5 enter r 1 into m(x 2 ,x 5 )enter r 2 into m(x 2 ,x 5 )create subject x

7

delete r 1 from m(x 2 ,x 5 )destroy subject x 2 enter r 1 into m(x 7 ,x 5 )...

create subject x 2 create object x 5 enter r 1 into m(x 2 ,x 5 )enter r 2 into m(x 2 ,x 5 ) ! create subject x 7 delete r

1 from m(x

2 ,x

5 )

destroy subject x 2 enter r 1 into m(x 7 ,x 5 )...


Example



72/134


,

3. Remove the last create subject operation in the sequence and substitute eachfollowing reference to this subject by a reference to s init

Repeat until all create subject operations are removed (apart from the initialcreate subject s init operation)

create subject s init create subject x 2 create object x 5 enter r 1 into m(x 2 ,x 5 )enter r 2 into m(x 2 ,x 5 ) ! create subject x

7

delete r 1 from m(x 2 ,x 5 )destroy subject x 2 enter r 1 into m(x 7 ,x 5 )...

create subject s init create subject x 2 create object x 5 enter r 1 into m(x 2 ,x 5 )enter r 2 into m(x 2 ,x 5 ) ! create subject x

7

delete r 1 from m(x 2 ,x 5 )destroy subject x 2 enter r 1 into m( s init ,x 5 )...

create subject s init create subject x 2 create object x 5 enter r 1 into m( s init ,x 5 )enter r 2 into m( s init ,x 5 )create subject x

7

delete r 1 from m( s init ,x 5 )destroy subject x 2 enter r 1 into m( s init ,x 5 )...


Example



73/134


,

Note

After step 3, Apart from s init , the sequence no longer creates any subjects All rights of the formerly created subjects accumulate in s init The sequence is “more finite”




74/134


,

4. Same as steps 2 and 3 for objects

create subject s init create subject x 2 create object x 5 enter r 1 into m( s init ,x 5 )enter r 2 into m( s init ,x 5 ) ! create subject x

7

delete r 1 from m( s init ,x 5 )destroy subject x 2 enter r 1 into m( s init ,x 5 )...

create subject s init create object o init create subject x 2 create object x 5 enter r 1 into m( s init , o init )enter r

2 into m( s

init , o

init )

create subject x 7 delete r 1 from m( s init ,x 5 )destroy subject x 2 enter r 1 into m( s init , o init )...


Example



75/134


,

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


2 into m( s

init , o

init ) !



2 into m( s

init , o

init )



Example



76/134


,

This sequence still leaks r , but its length it at most

(|S q |+1) • (| Oq |+1) • | R | + 2 ,because

Each enter primitive Operation now enters a new right into a cell The number of cells is = (| S q |+1) • (| O q|+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.


Assessment of Theorems


77/134


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: canonly create empty ACM columns)

! Are strong wrt. analysis ! safety decidable, automated tools

Consequences Restricted calculus fragments Heuristic analysis methods



78/134


79/134


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


Heuristic Analysis Methods


80/134


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



81/134


82/134


83/134


For the HRU Safety property analysis, Heuristics "

Exploit semi-decidability of the HRU-Safety problem Search for right leaks Assess a state sequence‘s probability to leak a right Accordingly channel the growth of state space (tree with root q)

q

q‘

q i

q i‘



84/134


Heuristic-based Decisions

Simulation step: $ (q i,e ), e =(* , x )! choice of state q i ! choice of action * ! choice of parameters x

q

q‘

q i

q i‘

$(q i,e )



85/134


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



86/134


87/134


88/134

Summary HRU Models


89/134


Goal

Analysis of right proliferation Computability of such analyses

Method

Combination of ACMs and deterministic automata

ResultsSafety not decidable in general!

HRU model family, domain-specific calculus fragments! heuristic based analysis methods



90/134


91/134


How it works:

Foundation of a TAM model is an HRU model (Q,#

, $ , q0) whereQ = 2 S x 2O x M However, S & O; objects in O-S : “pure“ objects

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

3.2.1.1.3 The Typed Access Matrix Model

m s 1 s 2 o1 o2 o3s 1s 2

Object set O


92/134


93/134


The Authorization Scheme

$ : Q x#

!

Q is defined by a set of expressions in the pattern

where! q =(S q,O q,m q) ! Q, " ! A

! x ! (S q % O q)k x ! {(o, t o)| o ! O q, t o ! T , t (o)=t o}k ! r 1 ... r m ! R! x s i ! S q, x o i ! O q-S q where

s 1 ... s m, o1 ... om are vector indices of the parameters in x , 1 ' s i ,o i ' k! p 1 " p n TAM primitive operations, see below


( )

fi

;...;then

,

...

,if

1

1 11

n

osqm

osq

p p

x x mr

x x mr ,x q,

mm!

"

"!=# $


94/134


Implicit Addendum to Authorization Scheme: Type Checking

( )

fi

;...;

then

,

...,

1

1 11

n

osqm

osq

p p

x x mr

x x mr

mm!

""!

!=

!

!==

k x k

x

t x t

t x t ,x q,

)(...

)(if :11

" #



95/134


96/134


TAM Primitives

enter r into m(x s ,x o ) delete r from m(x s ,x o )

create subject x s of type t s create object x o of type t o

destroy subject x s destroy object x o

(with their obvious semantics)

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


The Works


97/134


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)



98/134


99/134


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, C hris} Objects O=S % {ProjectXFile } Types T ={s, cs, co } (= regular subject, confined sub/object) where

t ( Ann ) = st (Bob ) = st (Chris ) = cst (ProjectXFile ) = co



100/134


The Works

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

m Ann: s Bob: s ProjectXFile : co

Ann: s own, read, write

Bob: s


SalesFlyer

R&D

Sales

Chris

Ann

Bob

owns

no information flow

ProjectXFiles


101/134


102/134


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

m Ann: s Bob: s ProjectXFile : co Chris: cs

Ann: s own, read, write

Bob: s cread parent

Chris: cs read


SalesFlyer

R&D

Sales

Chris

Ann

Bob

owns

no information flow

ProjectXFiles


103/134


The Protection Scheme

(a) command createOrconObject (s 1: s , o: co )create object o of type co ;enter own in m (s 1,o); enter read in m (s 1,o);

enter write in m (s 1,o);end

(b) command grantCRead (s 1: s , s 2: s , o: co )

if own ! m(s 1,o) then enter cread in m (s 2,o);

fiend



104/134


105/134


(d) command revokeCRead (s 1: s , s 2: s , o: co ) (Ann revokes cread from Bob)if own ! m(s

1,o) then

delete cread from m(s 2,o);fi

end

(e) command destroyOrconObject (s 1: s , o: co ) (Ann destroys CO ProjectXFile)if own ! m(s 1,o) then

destroy object o;fi

end


SalesFlyer

R&D

Sales

Chris

Ann

Bob

owns

no information flow

ProjectXFiles


106/134


(f) command revokeRead (s 1: s , s 3: cs , o: co ) (Ann destroys CS Chris)if own ! m(s

1,o) , read ! m(s

3,o) then

destroy subject s 3;fi

end

(g) command finishOrconRead (s 2: s , s 3: cs ) (Bob destroys CS Chris) if parent ! m(s 2,s 3) then

destroy subject s 3;fi

end


SalesFlyer

R&D

Sales

Chris

Ann

Bob

owns

no information flow

ProjectXFiles


107/134


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



108/134


Characterization of Acyclic TAM Models

Type Creation Graphs:Relation canCreate : (u,v ) ! canCreate # subjects of type u can create objects of type v

t i ! {t 1" t k } is called child type in * ! A # t i is type of a subject or object created in * (else t i 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



109/134


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 they1. just remove rights and2. 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



110/134


Professional TAM Model Applications

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


IBAC Summary


111/134


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



112/134


Model Spectrum

Static models:! Access control functions f : S x O x A ! {granted, denied}! Access control matrices: m: S x O ! 2 A

! 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 safetyMajor problem: decidability! restricted calculus fragments (monotonous, static, ..., typed models)! heuristic analysis algorithms



113/134


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


3.2.1.2 Role-based Access Control Models


114/134


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: >10 6 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



115/134

Idea


116/134


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

Brother Tuck

Nurse Kathy

read EPRs

write EPRs

read medications

write check records

WardPhys.

Nurse

user-to-role relation role-to-right relation

& &


IBAC& RBAC


117/134


IBAC Subjects, objects, rights for executing operations Access rules based on identifications of subjects and objects

Operation

Subject Object?

SO



118/134


119/134


120/134


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 Roles Permis-sions


121/134


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 permissionsassociated to roles (static)! “Each project leader is allowed to ...“

Users Roles Permis-sions

UA PA



122/134


Sessions reflect dynamic role assignments: a session s ! S is createdwhen a user logs in

! session-to-user assignment user : S ! U associates a session with auser

! session-to-roles assignment roles : S ! 2 R associates a session witha set of roles (that are active in a session)

Users RolesUA PA

static

dynamic

Operation

Subject Object?


Permis-sions

Session rolesuser


123/134


Access Control Function f With OP, set of operations,

“A role r exists that contains the permission to execute op on o, and thisrole is currently assigned to a session s that is active for user u”

User

Role

PA

Session

roles

user

Session

Session

Role

Role

Permission


Permission

Permission

f : U ! O ! OP " {true ,false }

f (u ,o,op ) !true | #r $ R ,s $ S : u = user (s ), r $ roles (s ), ( o,op ), r ( ) $ PAfalse | else

%&'

('

RBAC FamilySandhu 1996


124/134


RBAC 0: basic model

RBAC 1: RBAC 0 plus role hierarchies RBAC 2: RBAC 0 plus constraints RBAC 3: consolidation; RBAC 0 plus RBAC 1 plus RBAC 2

RBAC 1 RBAC 2

RBAC 3

RBAC 0


RBAC 1: Role Hierarchies


125/134


Observation Roles within an organization often overlap

! users in different roles share permissionsExample:

Permissions of project member are part of permissions of project manager! role definitions in RBAC 0 contain redundancy

! Permissions must be defined in each such role

GoalTo eliminate redundancy

ApproachRole hierarchy: Permission inheritance between roles



126/134


Examples

Project manager

Tester Programmer

Project staff

Head physician

Ward physiciansurgery

Ward physicianENT

Apprentice physician

Nursing staff

Physician



127/134


Hierarchy Modeling:

Lattices and Dominance Relations

Lattice: a tuple ( C , ' ) Class set C Partial ordering ” ' “

Properties Reflexive: " c ! C : c ' c Anti-symmetric: " c,d ! C : c ' d and d ' c ( c = d Transitive: " c,d,e ! C : c ' d and d ' e ( c ' e

Examples (! , ' ) (2 X , &), X arbitrary set



128/134


Role Hierarchy Modeling Class set R (roles) Hierarchy relation” ' “:

r 1 ' r 2 # r 1 passes permissions to r 2

Interpretation Reflexivity: a role inherits its own permissions

" r ! R : r ' r Anti-symmetry: roles that mutually inherit permissions are identical:

" r 1, r 2 ! R : r 1 ' r 2 and r 2 ' r 1 ( r 1 = r 2

Transitivity:

" r 1, r 2, r 3 ! R : r 1 ' r 2 and r 2 ' r 3 ( r 1 ' r 3



129/134


Example

Project staff ' TesterProject staff ' ProgrammerTester ' Project managerProgrammer ' Project manager

#


Project manager

Tester Programmer

Project staffpasses

permissions

passespermissions


130/134


131/134

RBAC 2: Constraints


132/134


Observation People may not assume certain roles at the same time

! mission- and security criticalExample: “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



133/134


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 othermodel components such as UA, PA , user , or roles


RBAC Summary


134/134

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

ch3 system security

Documents