12/2/2015 Prof. Ehud Gudes Security Ch 1 1 Chapter 2 Security Policies and Models Stallings Chapters 4,10 Article [J3]

04/18/23Prof. Ehud Gudes Security

Ch 1 1

Chapter 2

Security Policies and Models

Stallings Chapters 4,10Article [J3]

Prof. Ehud Gudes Security Ch 2

Basic Concepts

Security Policies

Security Mechanisms

Security Models

Authorization or Security specifications


Policies and Mechanism

Policies – general guidelines on authorization in the system, examples:Students can see their gradesOnly instructors can change grades

Mechanisms – techniques to enforce the policiesAccess controlEncryption


Ch 2 4

Institution Policies

Laws, rules and practices that regulate how an institution manages and protects resources. Another definition is: high-level guidelines concerning information security.

Computer mechanisms should enforce these policies.


Ch 2 5

Principles of Security Policy

Least privilegeIndividual responsibilityExplicit authorizationSeparation of dutyAuditingredundancy


Categories of Security Policies

Mandatory vs. Discretionary (Need to Know).

Ownership vs. AdministrationCentralized vs. DistributedClose vs. OpenName, Content or Context dependentIndividual, Group or Role basedGranularity of PolicyInformation Flow Control based


Ch 2 7

Some security policies

Open/closed systems--In a closed system everything is forbidden unless explicitly allowed

Need-to-know (Least privilege)-- Give just enough rights to perform duties

Ownership - Information belongs to the institution versus private ownership

Access granularity: access types or units of access (files, individual records, etc.)


Ch 2 8

Example of university policies

An instructor can look at all the information about the course he is teaching.

An instructor can change the grades of the students in the course he is teaching

A student may look at her grades in a course she is taking

The department head can add/delete course offerings

The department head can add/delete students from course offerings

Faculty members can look at information about themselves


Examples for Authorization specifications

John has a Faculty type of access to course: Operating Systems

Bill has a student type of access to course: Data Structures

Mary (secretary) has a Read/write access to all grades files

Access Control Policies


Ch 2 11

Security Policies and models

A security model is a formal definition of a security policy

04/18/23 12

Are stated in terms of a set of security objects, security subjects, and access privileges

Basic primitives:

•Users can protect the data they "own". •The owner may grant access to others. •The owner may define the type of access (read, write execute, ...)

given to others. •Granting and revoking of access permission is under the discretion

of the users themselves.

Discretionary Access Control Policy (DAC)

The Formal model: Access matrix


Ch 2 13

Mandatory Security Policy

Access control policy is beyond the control of individual owner, but is based on global decisions on object secrecy and subjects clearance


Ch 2 14

Security objects and security subjects are assigned to security labels.

Confidential < Classified < Secret < Top_Secret

Public < Company_Confidential < High_Security

The security level of an object O is called its classification, class (O). A subject S must be cleared to access sensitive information, clear (S).

A subject can access an object if the clearance level of the subject is at least as high as the classification of the object.

clear (S) class(O)

Military Security Model


Ch 2 15

Role-based Policy

Access control policy is based on the concept of a Role, where permissions are Assigned to Roles and roles are assigned to users

Several RBAC models


Ch 2 16

Policy combinations

Chinese Wall policy—Information is grouped into “conflict of interest “classes and a person is allowed access to at most one set of information in each class

Originator controlled (ORCON)—A document is released only to people or units in a list specified by the originator

04/18/23 17

A security model is an abstraction used to represent a security policy of an organization.

Security Object

Passive entity, that contains or receives information (database, relation, view, factof reality, a tuple, but also a memory segment, a printer ,...)

Security Subject

Active entity, often in the form of a person (user) or process operating on behalf of a user. Security subjects are responsible for a change of a database state and cause information to flow within different objects and subjects.

Models of security


DAC policy:The Access Matrix Model

Subjects - users, groups, applications, transactionsObjects - Files, programs, databases, relations, URLs Access-types - Read, write, create, copy, delete, execute,

killAuthorization commands - enter, remove, transferAuthorizers - Owners, users, administrators


Ch 2 19

Access matrix authorization rules

Basic rule ( s, a, o ) , where s is a subject (active entity), a is an access type , and o is an object

Extended rule ( s, a , o , p ) , where p is a predicate (access condition or guard )

Basic assumption: Subjects were authenticated (see chapter 5)


Ch 2 20

The Access Matrix ModelOBJECTS

SUBJECTS

SubjectsFilesDevices

S1S2F1F2D1D2

S1CallReadWrite

Seek

S2SendReadRewind

S3KillDelete

Capatibility Lists

Access Lists


Ch 2 21

Domains - the Access Table

a table of (domain,object) that stores permissions adding the domains to the objects represents domain

switches as well


Ch 2 22

Protection mechanisms - Domains

Domains do not have to be disjoint domain can be associated to a user, a process, a

procedure (i.e. its variables)commonly, a process runs in one domain at one

timethe domain of a process may need to be switched

to enable different operations switching domains is a well-defined operation of

domains


What’s the difference between a Subject and a Domain

A Subject is usually a process. During its life-time, a subject may acquire rights or lose them. At a particular point of time, a subject has a given set of rights that’s a Domain!


Ch 2 24

Administration of Access Matrix – Graham & Denning model

Copy rights - in the same column, to other domains (the copy flag) transfer; copy with right; just copy

Owner rights - anything in the same columnenabling access rights to object, in other domains

Control - only applies to domain-domain cells and enables one domain members to control other domain access rights

04/18/23 25

Protection System CommandsCommandPre-ConditionEffect

Create object o-Add column for o in A; place owner in A[x,o]

Create subject s-Add row for s in A; place control in A[x,o]

Delete object oOwner in A[x,o]Delete column o

Delete subject sControl in A[x,s]Delete row s

Read access right of s on oControl in A[x,s] or Owner in A[x,o]

Copy A[s,o] to x

Delete access right r of s on oControl in A[x,s] or Owner in A[x,o]

Remove r from A[s,o]

Grant access right r to s on oOwner in A[x,o]Add r to A[s,o]

Transfer access right r or r* to s on o

r* in A[x,o]Add r or r* to A[s,o]


Ch 2 26

The HRU Model The Harrison-Ruzzo-Ullman model (called the HRU model) is very similar to the

Graham-Denning model. The model is based on commands, where each command involves conditions and primitive operations.

The structure of a command is as follows.Command name(o1,o2,…,ok)

if r1 in A[s1,o1] and

r2 in A[s2,o2] and

. . .

rm in A[sm,om]

then

op1

op2

. . .

opn

end


Ch 2 27

enter r into A[s,o]

חדש תנאי מצב

Ss

Oo

SS '

OO '

),(),(:],[],[' 111111 osososAosA

}{],[],[' rosAosA


Ch 2 28

delete r from A[s,o]


Ss

Oo

SS '

OO '

),(),(:],[],[' 111111 osososAosA

}{],[],[' rosAosA


Ch 2 29

create subject s’


Os '

}'{' sSS }'{' sOO

OoSsosAosA ,:],[],['OoosA :],'[' SsssA :]',['


Ch 2 30

create object o’


Oo '

SS '}'{' oOO

OoSsosAosA ,:],[],['

SsosA :]',['


Ch 2 31

destroy subject s’


Ss '

}'{' sSS

}'{' sOO

',':],[],[' OoSsosAosA


Ch 2 32

destroy object o’


So '

SS '

}'{' oOO

',':],[],[' OoSsosAosA

Oo '


Ch 2 33

הגנה למדיניות דוגמא

ס קובץ אל גישה סמאותיבקרת מאפשרת ההגנה מדיניות

הקובץ אל זמנית בו לגשת אחד לנתין רק שלו הסיסמא את לשנות ניתן נתין לכל -לroot נתין כל של הסיסמא את לשנות מותר

אחר


Ch 2 34

הגישה בקרת מנגנון

בקרת מדיניות את ליישם המנגנון של תפקידוהגישה

תצא לא שהמערכת לוודא חייב המנגנוןאסור למצב ותגיע מותר ממצב

לוודא המנגנון על " י עפ מותרים יהיו במערכת המצבים מעברי כל

המדיניות המנגנון את לעקוף ניתן לא


Ch 2 35

למנגנון דוגמא

הרשאות שתי נגדירpasswd : נתיןp של הסיסמא את לשנות יכול

" qנתין ם אם

pwmutex: של הסיסמא את לשנות pניתןם" אם

],[passwd qpA

],[pwmutex ppA


Ch 2 36

ההגנה מדיניותמצב (Q=(S,O,A " ם אם מותר הוא

: הבאים התנאים שני מתקיימים מסוג הגישה במטריצת אחת כניסה בדיוק קיימת

[A[p,q ההרשאה נמצאת pwmutexשבה ההרשאהpasswd מסוג בכניסות רק נמצאת

[A[p,q כאשרq=p אוp=root : התחלתי מצב

pwmutex- ב A[root,root]נמצא passwd מסוג הכניסות בכל A[p,p]נמצאת

A[root,p]ו-


Ch 2 37

) המשך ) למנגנון דוגמא

פקודות נתין הוספת נתין ביטול ס change.passwdסמא : ישנוי : לקובץ גישה הרשאת transfer.mutexהעברת

Problem: Design the HRU commands to implement the above policies. Prove correctness


Ch 2 38

change.passwd

command change.passwd(p,q)if pwmutex in A[p,q]and passwd in A[p,q]thenסיסמא שינוי בצעend;


Ch 2 39

transfer.mutex

command transfer.mutex(p,q,p1,q1)If mutex in A[p,q]then

delete mutex from A[p,q]enter mutex to A[p1,q1]

End

Now only one user can change the password at a time!


Ch 2 40

Implementing Access Matrix - Access Control ListsThe access matrix is too large and

too sparse to be practicalIt can be stored by columns:

Objects have ordered lists of domains that can access them

Access bits RWX express access to files by users and groups

Can be expressed asFile1: (Amnon,staff,RWX)File2: (*,student,R--), (Rachel,*,---)File3: (Mike,*,R-X)


Ch 2 41

Implementing Access Matrix - Capability Lists

“Slicing” the protection matrix by rowsUsers and processes have capability lists

which are lists of permissions for each object appearing in a domain

Hard to revoke access to objects, have to be found in c-lists.

Capabilities are “special” objects, never accessible to user space objects - better protection

Generic operations on c-lists Copy capability (from one object to another) Copy Object (with capability) Remove capability (an entry of the c-list)


Ch 2 42

Implementing Access Matrix – in Real OSs (chapter 5)

Unix/Linux – generalized ACLs

MS Windows – ACLs

Multics – Capabilities and ACLs


Ch 2 43

Rights Amplification

Domain Switch (SVC, Set-Uid)Procedure Call (Capabilities)


Ch 2 44

The HRU Model The Harrison-Ruzzo-Ullman model (called the HRU model) is very similar to the

Graham-Denning model. The model is based on commands, where each command involves conditions and primitive operations.

The structure of a command is as follows.Command name(o1,o2,…,ok)

if r1 in A[s1,o1] and

r2 in A[s2,o2] and

. . .

rm in A[sm,om]

then

op1

op2

. . .

opn

end


Harison-Ruso-Ullman Model

Access matrix with general commands Concept of system safetyIs there an algorithm to decide whether

a given set of commands can lead to an unsafe state?

The general problem is Undecideable!


Harison-Ruso-Ullman Model

Each HRU command is mapped into a write on a Turing machine tape

The Safety problem is reduced into the Halting problem!

Special case – each command has only one action – algorithm is decidable but may be exponential ([P] sidebar 5-2)


Ch 3 47

The HRU Model


HRU model implications

Very negative! Cannor prove safety of a general system

But fortunately most systems have restrictive policies

For example, in Unix only owner can change access to an owned object

Complexity? – O(1)!


Ch 2 49

Take-Grant Model

More restrictive then HRU, thereforeSafety decisions are polynomial


Ch 2 50

Models of SecurityCreation of

an objectS

Revocation of a right

Granting of a right

Taking of a right

S O P

S OqUr

Grant

r

S O PrTake

S Or

becomes S Oq

S O PrGrant

S O PrTake

r

r

becomes

becomes

Creating an Object; Revoking, Granting, and Taking Access Rights


Ch 2 51

Create(o,r). A new node with label o is added to the graph. From s to o there is a directed edge with label r, denoting the rights of s on o.

Revoke(o,r). The rights r are revoked from s on o. the edge from s to o was labeled qUr; the label is replaced by q. Informally, s can revoke its rights to do r on o.

Grant(o,p,r). Subject s grants to o access rights r on p. a specific right is grant. Subject s can grant to o access rights r on p only if s has grant right on o, and s has r rights on p. Informally, s can grant (share) any of its rights with o, as long as s has the right to grant privileges to o. An edge from o to p is added, with label r.

Take (o,p,r). Subject s takes from o access rights r on p. A specific right is take. Subject s can take from o access rights r on p only if s has take right on o, and o has r rights on p. Informally, s can take any rights o has, as long as s has the right to take privileges from o. An edge from s to p is added with label r.

Models of Security, cont.


Ch 2 52

Mandatory Access Control (MAC) Multilevel model

In this model users and data are assigned classifications or clearances.

Classifications include levels (top secret, secret,…), and compartments (engDept, marketingDept,…).

For confidentiality, access of users to data is based on rules defined by the Bell-LaPadula model, while for integrity, the rules are defined by Biba’s model.


Ch 2 53

The Information Flow Problem of DAC (I)

Users Rights

User: Alice

r: Alice; w: Alice

User: Bob

r: Bob; r,w: Alice

User Bob cannot read the file A!

File A

File B


Ch 2 54

The Information Flow Problem of DAC (II)

Information Flow

User: Alice

r: Alice; w: Alice

User: Bob

r: Bob; r,w: Alice

User Bob can read contents of the file Acopied to file B

File A

File B

Pgm X

TH

Read

Write

Bell-LaPadula (BLP) Model

developed in 1970sas a formal access control modelsubjects and objects have a security

classtop secret > secret > confidential >

unclassifiedsubject has a security clearance levelobject has a security classification levelclass control how subject may access an

object


Ch 2 56

We call the level of a subject:Clearance and the level of an object: Class

• Simple Security Property: Successful read access: Clear (S) Class (O)

• *-Property: Successful write access: Class (O) Clear (S)

That is: No Read-up and No Write-down

Bell and LaPadula Model (1)


Ch 2 57

The *-property protects information from being ‚written-down‘ along the hierarchy ofsensitivity levels.

‚Write‘ if no ‚read‘ to higher classified data!

O1

S1 O2

O3

S2

O5

O4

(w)

(r)(r)

(r) (r)

(w)

(w)

(w)

low

high

O S

Bell and LaPadula Model (2)

BLP Formal Description (Stallings)based on current state of system (b, M, f, H):

(current access set b, access matrix M, level function f, hierarchy H)

three BLP properties:ss-property: (Si, Oj, read) has fc(Si) ≥ fo(Oj).

*-property: (Si, Oj, append) has fc(Si) ≤ fo(Oj) and

(Si, Oj, write) has fc(Si) = fo(Oj)

(**) ds-property: (Si, Oj, Ax) implies Ax M[Si. Oj ]

BLP give formal theoremstheoretically possible to prove system is securein practice usually not possible

(**) Stallings includes DS-property – not common, we Dont!also we treat Append and Write the same!

BLP Example

BLP Examplecont.

BLP Examplecont.


Ch 2 62

Problems of BLP

1. The need for a Trusted subject (to write non-secret info.)

Solution: high water mark! – get the sensitivity level of the highest level accessed object during the program execution so far…

2. The problem of covert channels.3. No access-control when all subjects and all

objects are at the same level – can add DAC to MAC…


Ch 2 63

Objective of the model: trying to keep the integrity

Biba defines ‚integrity levels‘ which are analogous to the sensitivity levels of Bell and

LaPadula. Objects with a high level of integrity should not be modified from subjects with a

lower level of integrity.

Simple Integrity Property:

Subject S can modify object O, if I (S) I

Subject S can read object O , if I (O) IS

Integrity *-Property:

If subject S has read access to object O with integrity level I (O), S can have write access to object P only if I (O) I (P).

The *-property protects information from flowing up along the hierarchy of integrity levels.

Biba Model


Ch 2 64

O1

S1 O2

O3

S2

O5

O4

(w)

(r)(r)

(r) (r)

(w)

(w)

(w)

low

high

(w)

(w)

(r)

(r)

(r)

(r)

(w)

(w)

BLP

(w)

BIBA

Biba Model (Cont. )


Ch 2 65

Security subjects are assigned to roles.

Each transaction must be well-formed. A well-formed transaction operates only on a

predefined set of data by using a restricted set of operations. It must be formally verified that

all security and integrity properties are satisfied.

Data may only be accessed through a well-formed transaction assigned to a role. In the case a

user of a certain role requires additional information, another user (acting in a separate role)

has to use a well-formed transaction from his transaction domain to grant the user temporary

permission to execute a larger set of well-formed transactions (separation of duty).

Roles need to be defined in a way that makes it impossible for a single user to violate the

integrity of a system.

The Clark and Wilson Model


Ch 2 66

Additional Models

The Lattice modelThe chinese-wall

modelThe Confinement

modelThe Non-Interference

modelexample: Myers model


Ch 2 67

The Lattice Model (I)

Lattice for a company’s security policy

Public

(CC,E,M)

(CC,M)(CC,E)


Ch 2 68

1. (L, C) (L’, C’) if and only if L L’ and C C’

and (interpreting the least upper bound operator as a class-combining operator)

2. (L, C) (L’, C) = (max(L, L’), C C’)

Example. A company’s policy forms a lattice with levels Public and Company Confidential (CC) and categories Engineering (E) and Marketing (M). The lattice is shown in figure 4.9, where an arrow indicates that information may flow along that path.

SC = {Public, CC, E, M}Public CC(Public, E) CC = (CC, E)

And(Public, E) (CC, E, M) = (Public, E)

The Lattice Model (II)

69

B1 B2 Z1

Z2

Z3

Company Information

Conflict ofinterest class i

Conflict ofinterest class j

Company i.n

Company i.l Company i.m

Company j.l

Consultant s Consultant s'

information flow

Chinese Wall

The Chinese Wall Policy

A subject S is granted write access to object O only if S has no read access to an object O’ where

O and O` are in a conflict of interest class

Chinese Wall Model


Ch 2 71

Simple Security Rule: A subject S can read an object O only if

O is in the same DS as an object already accessed by S,

or O belongs to a CI from which S has not yet accessed any information.

*-property Rule: : A subject S can write an object O only if:

S can read O according to the simple security rule, and All objects that S can read are in the same DS as O.

Chinese Wall Model - Rules


Ch 2 72

Measuring information flow

Until now we saw models like BLP where information flow is Binary – either it exists or not

What if there is partial information flow – how can we measure it?

The concept of ENTROPY (Shanon)

Also the second law of Thermodynamics – Entropy always rises

)(log)()( 2 K

K

K XPXPXH

Entropy - Examples

For a fair coin (probability ½ for each side)H = - (1/2*log2 (1/2) + 1/2*log2 (1/2) =

-(-1/2 -1/2) = 1That is: one bit of information = one bit of

uncertainty!If the coin has probabilities (1/4 and 3/4)

then H = - (1/4*log2 (1/4) + 3/4*log2 (3/4)) =

-(-1/2 + 3/4 * (log3 -2)) = (-0.5-0.30) = 0.80

We are more certain therefore there is less information or less uncertainty!


Models of Information Flow - Entropy

Conditional Entropy

Where

)(log)()( 2 K

K

K XPXPXH

)/(log)/()/( 2 YXPYXPYXH KK

K

)/( YXP K Probability of XK given Y


Ch 2 75

Uses of Entropy

For Computing Information flow within a program (system) e.g. the example:

if x==1 then y = 1

For evaluating ciphers by comparing: H(M) and H(M|C)For evaluating Noise-based communication

All in Shanon’s original paper!


Ch 2 76

Conditional Entropy (Cont.)

The Husband/Wife example of [J3]

See Hovereth, Section 2.2.8

77

Role-Based Models

• Authorization is defined by by Roles

• Permissions are assigned to Roles

• Users are assigned to Roles


Ch 2 78

Roles and PermissionsMedical_Staff: collectively, responsible for all aspects of direct

patient care.

Nurse: Direct involvement with patient care on a daily basis.

Physician: Handle the medical needs (diagnosis, treatment, etc.) for patients.

Pharmacists: Control the supply and distribution of all drugs throughout the hospital.

Technician: Provide a variety of medical testing support for Patients.

Therapist: Evaluate patients and develop treatment plans for therapy.

Staff_RN: Administer direct care to patients and implement the physician treatment plan.


Ch 2 79

Discharge_Plug: Link between patients and outside agencies for care after discharge.

Education: Educate both the nursing staff and patients regarding new treatment and self care.

Manager: Responsible for the day-to-day operation of a nursing unit

Director: (For Physician or Pharmacist) Responsible for the day-to-day operation of their respective

department/medical service.

Private: the physician within his/her office/private–practice setting.

Attending: A physician that hes privileges to admit and treat patients at a hospital.

Roles and Permissions, cont.


Ch 2 80

The User-Role Definition Hierarchy

User Types, User Classes and Selected User Roles

Medical StaffUsers

Nurse Physician Pharmacist Technician Therapist

Support Staff

Support

Prepare room Volunteer Security

Other

Patient Spouce


Ch 2 81

Role-Based Models

RBAC0 – Users, Roles, Permissions, Sessions

RBAC1 – RBAC0 + Role-hierarchies

RBAC2 – RBAC0 + Constraints

RBAC3 – RBAC0 + Role-hierarchies + Constraints


Ch 2

RBAC0

המודל הבסיסי עליו מתבססיםשאר המודלים.

Users(U)

Roles(R)

Userassignment

(UA)

Permissionassignment

(PA) Permissions(P)

Sessions(S)


Ch 2

RBAC1

היררכייתRole.ים-

Users(U)

Roles(R)

Userassignment

(UA)


(PA) Permissions(P)

Sessions(S)

Role hierarchy(RH)


Ch 2

RBAC1

היררכיה שלRoleים-:

.קשר אב ובן.הרשאות אפקטיביות וישירות

Employee[Read]

Developer[Read,Develop]

QA[Read,Test]

Admin[Read,Test,Develop]


Ch 2

RBAC1

הגבלת ירושה.

Employee[Read]

Developer[Read,Develop]

QA[Read,Test]

Admin[Read,Test,Develop]

Developer'[Read,Develop,Build]


Ch 2

RBAC2

מודל האילוציםRole.ים מנוגדים-

Users(U)

Roles(R)

Userassignment

(UA)


(PA) Permissions(P)

Sessions(S)

Constranits


Ch 2

RBAC3

המודל המשולב: אילוצים והיררכייתRoles .

Users(U)

Roles(R)

Userassignment

(UA)


(PA) Permissions(P)

Sessions(S)

Role hierarchy(RH)

Constranits

88

Constraints in RBAC – Separation of duties

Conflicts between Permissions – conflicting permissions cannot be in the same Role or in two roles with a common ancestor

Conflicts between Roles – the same user cannot be in two conflicting roles

Conflicting usersStatic constraints – max. number of

roles per user, permissions per role, etcDynamic constraints – session

dependent

NIST RBAC Model


Ch 2

המודל האדמיניסטרטיבי

בין -Roleהפרדה ל Roleרגילאדמיניסטרטיבי.

- ל משתמש .Roleהשמת

- ל הרשאה .Roleהשמת

השמתRole- .Roleל


Ch 2

-יםRoleהשמת משתמשים ל-

הענקתRole:למשתמש הגדרת תחומי אחריות שלRole אדמיניסטרטיבי על

.can_assignידי היחס

שלילתRole:ממשתמש הגדרת תחומי אחריות שלRole אדמיניסטרטיבי על

.can_revokeהיחס ידי – שלילה חלשהRole.אינו נשלל כתוצאה מירושה .שלילה חזקה – שלילת כל עץ הירושה


Ch 2 92

-ים Roleדוגמא להיררכית אדמיניסטרטיביים


Ch 2 93

-ים Role הדוגמא להיררכיית אדמיניסטרטיביים

Roleאדמיניסטרטי

בי

Roleתנאי מוקדם

קבוצתRoleים -

Role טווח

PSO1ED{E1,PE1,QE1}

[E1, PL1)

PSO2ED{E2,PE2,QE2}

[E2,PL2)

DSOED{PL1,PL2}(ED,DIR)

SSOE{ED}[ED,ED]

SSOED{DIR}(ED,DIR]

MLS Security for Role-Based Access Control

Role based access control (RBAC) can implement BLP MLS rules given:security constraints on usersconstraints on read/write permissionsread and write level role access

definitionsconstraint on user-role assignments

RBAC MLS Example

Tuval&Gudes - DBSEC 2006Conflicting permission set

R1 ru

R4 ru, ws

R3 ru, rs, ws

R6ru, rs ,

ws wts

R2 ws

R5 ws,wts

R7 ru, rs, rts, ws, wts

Can not be assign to any user

Resolution a. Creating a consistent graph – Algorithm 1b. Handling user-role assignments – Algorithm 2

12/2/2015 Prof. Ehud Gudes Security Ch 1 1 Chapter 2 Security Policies and Models Stallings Chapters 4,10 Article [J3]

Documents

security policy slide

ehud gudes security

information security

security specifications

principles of security

military security model

access control policies

access matrix slide