chapter 2 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 2 PowerPoint Presentation
Download Presentation
Chapter 2

Loading in 2 Seconds...

play fullscreen
1 / 96

Chapter 2 - PowerPoint PPT Presentation


  • 148 Views
  • Uploaded on

Chapter 2. Security Policies and Models Stallings Chapters 4,10 Article [J3] . Basic Concepts. Security Policies Security Mechanisms Security Models Authorization or Security specifications. Policies and Mechanism.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Chapter 2


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
chapter 2
Chapter 2

Security Policies and Models

Stallings Chapters 4,10

Article [J3]

Prof. Ehud Gudes Security Ch 1

basic concepts
Basic Concepts
  • Security Policies
  • Security Mechanisms
  • Security Models
  • Authorization or Security specifications

Prof. Ehud Gudes Security Ch2

policies and mechanism
Policies and Mechanism
  • Policies – general guidelines on authorization in the system, examples:
    • Students can see their grades
    • Only instructors can change grades
  • Mechanisms – techniques to enforce the policies
    • Access control
    • Encryption

Prof. Ehud Gudes Security Ch2

institution policies
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.

Prof. Ehud Gudes Security Ch2

principles of security policy
Principles of Security Policy
  • Least privilege
  • Individual responsibility
  • Explicit authorization
  • Separation of duty
  • Auditing
  • redundancy

Prof. Ehud Gudes Security Ch2

categories of security policies
Categories of Security Policies
  • Mandatory vs. Discretionary (Need to Know).
  • Ownership vs. Administration
  • Centralized vs. Distributed
  • Close vs. Open
  • Name, Content or Context dependent
  • Individual, Group or Role based
  • Granularity of Policy
  • Information Flow Control based

Prof. Ehud Gudes Security Ch2

slide7

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

Prof. Ehud Gudes Security Ch2

example of university policies
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

Prof. Ehud Gudes Security Ch2

examples for authorization specifications
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

Prof. Ehud Gudes Security Ch2

slide11

Security Policies and models

A security model is a formal definition of a security policy

Prof. Ehud Gudes Security Ch2

discretionary access control policy dac
Discretionary Access Control Policy (DAC)

The Formal model: Access matrix

mandatory security policy
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

Prof. Ehud Gudes Security Ch2

military security model
Military Security Model

Prof. Ehud Gudes Security Ch2

role based policy
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

Prof. Ehud Gudes Security Ch2

policy combinations
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

Prof. Ehud Gudes Security Ch2

dac policy the access matrix model
DAC policy:The Access Matrix Model
  • Subjects

- users, groups, applications, transactions

  • Objects

- Files, programs, databases, relations, URLs

  • Access-types

- Read, write, create, copy, delete, execute, kill

  • Authorization commands

- enter, remove, transfer

  • Authorizers

- Owners, users, administrators

Prof. Ehud Gudes Security Ch2

slide19

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)

Prof. Ehud Gudes Security Ch2

the access matrix model
The Access Matrix Model

Capatibility Lists

Access Lists

Prof. Ehud Gudes Security Ch2

domains the access table
Domains - the Access Table
  • a table of (domain,object) that stores permissions
  • adding the domains to the objects represents domain switches as well

Prof. Ehud Gudes Security Ch2

protection mechanisms domains
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 time
  • the domain of a process may need to be switched to enable different operations
  • switching domains is a well-defined operation of domains

Prof. Ehud Gudes Security Ch2

what s the difference between a subject and a domain
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!

Prof. Ehud Gudes Security Ch2

administration of access matrix graham denning model
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 column

enabling 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

Prof. Ehud Gudes Security Ch2

the hru model
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.

Commandname(o1,o2,…,ok)

ifr1 in A[s1,o1] and

r2 in A[s2,o2] and

. . .

rm in A[sm,om]

then

op1

op2

. . .

opn

end

Prof. Ehud Gudes Security Ch2

enter r into a s o
enter r into A[s,o]

Prof. Ehud Gudes Security Ch2

delete r from a s o
delete r from A[s,o]

Prof. Ehud Gudes Security Ch2

create subject s
create subject s’

Prof. Ehud Gudes Security Ch2

create object o
create object o’

Prof. Ehud Gudes Security Ch2

destroy subject s
destroy subject s’

Prof. Ehud Gudes Security Ch2

destroy object o
destroy object o’

Prof. Ehud Gudes Security Ch2

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

Prof. Ehud Gudes Security Ch2

slide34
מנגנון בקרת הגישה
  • תפקידו של המנגנון ליישם את מדיניות בקרת הגישה
  • המנגנון חייב לוודא שהמערכת לא תצא ממצב מותר ותגיע למצב אסור
  • על המנגנון לוודא
    • כל מעברי המצבים במערכת יהיו מותרים עפ"י המדיניות
    • לא ניתן לעקוף את המנגנון

Prof. Ehud Gudes Security Ch2

slide35
דוגמא למנגנון
  • נגדיר שתי הרשאות
    • passwd : נתין p יכול לשנות את הסיסמא של נתין q אם"ם
    • pwmutex : ניתן לשנות את הסיסמא של p אם"ם

Prof. Ehud Gudes Security Ch2

slide36
מדיניות ההגנה
  • מצב(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

Prof. Ehud Gudes Security Ch2

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

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

Prof. Ehud Gudes Security Ch2

change passwd
change.passwd

command change.passwd(p,q)

if pwmutex in A[p,q]

and

passwd in A[p,q]

then

בצע שינוי סיסמא

end;

Prof. Ehud Gudes Security Ch2

transfer mutex
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!

Prof. Ehud Gudes Security Ch2

implementing access matrix access control lists
Implementing Access Matrix - Access Control Lists
  • The access matrix is too large and too sparse to be practical
  • It 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 as
      • File1: (Amnon,staff,RWX)
      • File2: (*,student,R--), (Rachel,*,---)
      • File3: (Mike,*,R-X)

Prof. Ehud Gudes Security Ch2

implementing access matrix capability lists
Implementing Access Matrix - Capability Lists
  • “Slicing” the protection matrix by rows
  • Users 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)

Prof. Ehud Gudes Security Ch2

implementing access matrix in real oss chapter 5
Implementing Access Matrix – in Real OSs (chapter 5)
  • Unix/Linux – generalized ACLs
  • MS Windows – ACLs
  • Multics – Capabilities and ACLs

Prof. Ehud Gudes Security Ch2

rights amplification
Rights Amplification

Domain Switch (SVC, Set-Uid)

Procedure Call (Capabilities)

Prof. Ehud Gudes Security Ch2

the hru model1
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.

Commandname(o1,o2,…,ok)

ifr1 in A[s1,o1] and

r2 in A[s2,o2] and

. . .

rm in A[sm,om]

then

op1

op2

. . .

opn

end

Prof. Ehud Gudes Security Ch2

harison ruso ullman model
Harison-Ruso-Ullman Model
  • Access matrix with general commands
  • Concept of system safety
  • Is there an algorithm to decide whether a given set of commands can lead to an unsafe state?

The general problem is

Undecideable!

Prof. Ehud Gudes Security Ch2

harison ruso ullman model1
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)

Prof. Ehud Gudes Security Ch2

the hru model2
The HRU Model

Prof. Ehud Gudes Security Ch 3

hru model implications
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)!

Prof. Ehud Gudes Security Ch2

take grant model
Take-Grant Model

More restrictive then HRU, therefore

Safety decisions are polynomial

Prof. Ehud Gudes Security Ch2

models of security1

Creation of

an object

r

S

S

Revocation of a right

qUr

becomes

q

S

S

r

r

Granting of a right

Grant

Grant

S

S

S

S

becomes

r

P

P

P

P

O

O

O

O

O

O

O

r

Taking of a right

Take

Take

r

r

becomes

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

Models of Security

Prof. Ehud Gudes Security Ch2

models of security cont
Models of Security, cont.
  • 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.

Prof. Ehud Gudes Security Ch2

mandatory access control mac multilevel model
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.

Prof. Ehud Gudes Security Ch2

the information flow problem of dac i

Users Rights

r: Alice; w: Alice

File A

User: Alice

r: Bob; r,w: Alice

File B

User: Bob

User Bob cannot read the file A!

The Information Flow Problem of DAC (I)

Prof. Ehud Gudes Security Ch2

the information flow problem of dac ii

Information Flow

r: Alice; w: Alice

File A

User: Alice

Pgm X

Read

r: Bob; r,w: Alice

File B

TH

User: Bob

Write

User Bob can read contents of the file A

copied to file B

The Information Flow Problem of DAC (II)

Prof. Ehud Gudes Security Ch2

bell lapadula blp model
Bell-LaPadula (BLP) Model
  • developed in 1970s
  • as a formal access control model
  • subjects and objects have a security class
    • top secret > secret > confidential > unclassified
    • subject has a security clearance level
    • object has a security classification level
    • class control how subject may access an object
bell and lapadula model 1
Bell and LaPadula Model (1)
  • 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

Prof. Ehud Gudes Security Ch2

bell and lapadula model 2
Bell and LaPadula Model (2)

high

(w)

(w)

(r)

(r)

(w)

(w)

S2

S

S1

O2

O3

O5

O4

O

O1

(r)

(r)

low

Prof. Ehud Gudes Security Ch2

blp formal description stallings
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 theorems

    • theoretically possible to prove system is secure
    • in practice usually not possible

(**) Stallings includes DS-property – not common, we Dont!

also we treat Append and Write the same!

problems of blp
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…

Prof. Ehud Gudes Security Ch2

biba model
Biba Model

Prof. Ehud Gudes Security Ch2

biba model cont
Biba Model (Cont. )

BLP

high

BIBA

(w)

(r)

(w)

(r)

(r)

(w)

(w)

(r)

(w)

(r)

(w)

(w)

S1

S2

O1

O2

O3

O5

O4

(r)

(r)

(w)

(w)

low

(r)

Prof. Ehud Gudes Security Ch2

the clark and wilson model
The Clark and Wilson Model

Prof. Ehud Gudes Security Ch2

additional models
Additional Models
  • The Lattice model
  • The chinese-wall model
  • The Confinement model
  • The Non-Interference modelexample: Myers model

Prof. Ehud Gudes Security Ch2

the lattice model i

(CC,E,M)

(CC,E)

(CC,M)

Public

The Lattice Model (I)

Lattice for a company’s security policy

Prof. Ehud Gudes Security Ch2

the lattice model ii
The Lattice Model (II)

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)

Prof. Ehud Gudes Security Ch2

the chinese wall policy
The Chinese Wall Policy

Company Information

Consultant s

Consultant s'

Conflict of

interest class i

Conflict of

interest class j

Z2

Z1

B2

B1

Company i.l

Company i.m

Z3

Company j.l

Company i.n

information flow

Chinese Wall

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 rules
Chinese Wall Model - Rules

Prof. Ehud Gudes Security Ch2

measuring information flow
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

Prof. Ehud Gudes Security Ch2

entropy examples
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) = 1

That 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
Models of Information Flow - Entropy

Conditional Entropy

Where

Probability of XK given Y

Prof. Ehud Gudes Security Ch2

uses of entropy
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!

Prof. Ehud Gudes Security Ch2

conditional entropy cont
Conditional Entropy (Cont.)

The Husband/Wife example of [J3]

See Hovereth, Section 2.2.8

Prof. Ehud Gudes Security Ch2

role based models

Role-Based Models

  • Authorization is defined by by Roles
  • Permissions are assigned to Roles
  • Users are assigned to Roles
roles and permissions
Roles and Permissions

Medical_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.

Prof. Ehud Gudes Security Ch 2

roles and permissions cont
Roles and Permissions, cont.

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.

Prof. Ehud Gudes Security Ch 2

the user role definition hierarchy

Users

Medical Staff

Support Staff

Other

Nurse

Physician

Pharmacist

Technician

Therapist

Support

Patient Spouce

Prepare room

Volunteer

Security

The User-Role Definition Hierarchy

User Types, User Classes and Selected User Roles

Prof. Ehud Gudes Security Ch2

role based models1
Role-Based Models
  • RBAC0 – Users, Roles, Permissions, Sessions
  • RBAC1 – RBAC0 + Role-hierarchies
  • RBAC2 – RBAC0 + Constraints
  • RBAC3 – RBAC0 + Role-hierarchies + Constraints

Prof. Ehud Gudes Security Ch 2

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

Prof. Ehud Gudes Security Ch 2

rbac1
RBAC1
  • היררכיית Role-ים.

Prof. Ehud Gudes Security Ch 2

rbac11
RBAC1
  • היררכיה של Role-ים:
    • קשר אב ובן.
    • הרשאות אפקטיביות וישירות.

Prof. Ehud Gudes Security Ch 2

rbac12
RBAC1
  • הגבלת ירושה.

Prof. Ehud Gudes Security Ch 2

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

Prof. Ehud Gudes Security Ch2

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

Prof. Ehud Gudes Security Ch 2

constraints in rbac separation of duties
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 users
  • Static constraints – max. number of roles per user, permissions per role, etc
  • Dynamic constraints – session dependent
slide90
המודל האדמיניסטרטיבי
  • הפרדה בין Role רגיל ל-Role אדמיניסטרטיבי.
  • השמת משתמש ל-Role.
  • השמת הרשאה ל-Role.
  • השמת Roleל-Role.

Prof. Ehud Gudes Security Ch 2

slide91
השמת משתמשים ל-Role-ים
  • הענקת Role למשתמש:
    • הגדרת תחומי אחריות של Role אדמיניסטרטיבי על ידיהיחס can_assign.
  • שלילת Role ממשתמש:
    • הגדרת תחומי אחריות של Role אדמיניסטרטיבי על ידיהיחס can_revoke.
    • שלילה חלשה – Role אינו נשלל כתוצאה מירושה.
    • שלילה חזקה – שלילת כל עץ הירושה.

Prof. Ehud Gudes Security Ch2

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

Prof. Ehud Gudes Security Ch 2

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

Prof. Ehud Gudes Security Ch 2

mls security for role based access control
MLS Security for Role-Based Access Control
  • Role based access control (RBAC) can implement BLP MLS rules given:
    • security constraints on users
    • constraints on read/write permissions
    • read and write level role access definitions
    • constraint on user-role assignments
tuval gudes dbsec 2006 conflicting permission set
Tuval&Gudes - DBSEC 2006Conflicting permission set

Resolution

ru, rs,rts,ws, wts

R7

a. Creating a consistent graph –Algorithm 1

Can not be assign to any user

b. Handling user-role assignments –Algorithm 2

ru, rs,

ws wts

R5

R6

ws,wts

R3

ru, rs, ws

R4

ru, ws

R2

ws

R1

ru