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
Prof. Ehud Gudes Security Ch 2
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
04/18/23Prof. Ehud Gudes Security
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.
04/18/23Prof. Ehud Gudes Security
Ch 2 5
Principles of Security Policy
Least privilegeIndividual responsibilityExplicit authorizationSeparation of dutyAuditingredundancy
Prof. Ehud Gudes Security Ch 2
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
04/18/23Prof. Ehud Gudes Security
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.)
04/18/23Prof. Ehud Gudes Security
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
Prof. Ehud Gudes Security Ch 2
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
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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
Prof. Ehud Gudes Security Ch 2
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
04/18/23Prof. Ehud Gudes Security
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)
04/18/23Prof. Ehud Gudes Security
Ch 2 20
The Access Matrix ModelOBJECTS
SUBJECTS
SubjectsFilesDevices
S1S2F1F2D1D2
S1CallReadWrite
Seek
S2SendReadRewind
S3KillDelete
Capatibility Lists
Access Lists
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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
Prof. Ehud Gudes Security Ch 2
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!
04/18/23Prof. Ehud Gudes Security
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]
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
Ch 2 27
enter r into A[s,o]
חדש תנאי מצב
Ss
Oo
SS '
OO '
),(),(:],[],[' 111111 osososAosA
}{],[],[' rosAosA
04/18/23Prof. Ehud Gudes Security
Ch 2 28
delete r from A[s,o]
חדש תנאי מצב
Ss
Oo
SS '
OO '
),(),(:],[],[' 111111 osososAosA
}{],[],[' rosAosA
04/18/23Prof. Ehud Gudes Security
Ch 2 29
create subject s’
חדש תנאי מצב
Os '
}'{' sSS }'{' sOO
OoSsosAosA ,:],[],['OoosA :],'[' SsssA :]',['
04/18/23Prof. Ehud Gudes Security
Ch 2 30
create object o’
חדש תנאי מצב
Oo '
SS '}'{' oOO
OoSsosAosA ,:],[],['
SsosA :]',['
04/18/23Prof. Ehud Gudes Security
Ch 2 31
destroy subject s’
חדש תנאי מצב
Ss '
}'{' sSS
}'{' sOO
',':],[],[' OoSsosAosA
04/18/23Prof. Ehud Gudes Security
Ch 2 32
destroy object o’
חדש תנאי מצב
So '
SS '
}'{' oOO
',':],[],[' OoSsosAosA
Oo '
04/18/23Prof. Ehud Gudes Security
Ch 2 33
הגנה למדיניות דוגמא
ס קובץ אל גישה סמאותיבקרת מאפשרת ההגנה מדיניות
הקובץ אל זמנית בו לגשת אחד לנתין רק שלו הסיסמא את לשנות ניתן נתין לכל -לroot נתין כל של הסיסמא את לשנות מותר
אחר
04/18/23Prof. Ehud Gudes Security
Ch 2 34
הגישה בקרת מנגנון
בקרת מדיניות את ליישם המנגנון של תפקידוהגישה
תצא לא שהמערכת לוודא חייב המנגנוןאסור למצב ותגיע מותר ממצב
לוודא המנגנון על " י עפ מותרים יהיו במערכת המצבים מעברי כל
המדיניות המנגנון את לעקוף ניתן לא
04/18/23Prof. Ehud Gudes Security
Ch 2 35
למנגנון דוגמא
הרשאות שתי נגדירpasswd : נתיןp של הסיסמא את לשנות יכול
" qנתין ם אם
pwmutex: של הסיסמא את לשנות pניתןם" אם
],[passwd qpA
],[pwmutex ppA
04/18/23Prof. Ehud Gudes Security
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]ו-
04/18/23Prof. Ehud Gudes Security
Ch 2 37
) המשך ) למנגנון דוגמא
פקודות נתין הוספת נתין ביטול ס change.passwdסמא : ישנוי : לקובץ גישה הרשאת transfer.mutexהעברת
Problem: Design the HRU commands to implement the above policies. Prove correctness
04/18/23Prof. Ehud Gudes Security
Ch 2 38
change.passwd
command change.passwd(p,q)if pwmutex in A[p,q]and passwd in A[p,q]thenסיסמא שינוי בצעend;
04/18/23Prof. Ehud Gudes Security
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!
04/18/23Prof. Ehud Gudes Security
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)
04/18/23Prof. Ehud Gudes Security
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)
04/18/23Prof. Ehud Gudes Security
Ch 2 42
Implementing Access Matrix – in Real OSs (chapter 5)
Unix/Linux – generalized ACLs
MS Windows – ACLs
Multics – Capabilities and ACLs
04/18/23Prof. Ehud Gudes Security
Ch 2 43
Rights Amplification
Domain Switch (SVC, Set-Uid)Procedure Call (Capabilities)
04/18/23Prof. Ehud Gudes Security
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
Prof. Ehud Gudes Security Ch 2
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!
Prof. Ehud Gudes Security Ch 2
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 Ch 2
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)!
04/18/23Prof. Ehud Gudes Security
Ch 2 49
Take-Grant Model
More restrictive then HRU, thereforeSafety decisions are polynomial
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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.
04/18/23Prof. Ehud Gudes Security
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.
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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)
04/18/23Prof. Ehud Gudes Security
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!
04/18/23Prof. Ehud Gudes Security
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…
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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. )
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
Ch 2 66
Additional Models
The Lattice modelThe chinese-wall
modelThe Confinement
modelThe Non-Interference
modelexample: Myers model
04/18/23Prof. Ehud Gudes Security
Ch 2 67
The Lattice Model (I)
Lattice for a company’s security policy
Public
(CC,E,M)
(CC,M)(CC,E)
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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!
Prof. Ehud Gudes Security Ch 2
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
04/18/23Prof. Ehud Gudes Security
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!
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
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.
04/18/23Prof. Ehud Gudes Security
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.
04/18/23Prof. Ehud Gudes Security
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
04/18/23Prof. Ehud Gudes Security
Ch 2 81
Role-Based Models
RBAC0 – Users, Roles, Permissions, Sessions
RBAC1 – RBAC0 + Role-hierarchies
RBAC2 – RBAC0 + Constraints
RBAC3 – RBAC0 + Role-hierarchies + Constraints
04/18/23Prof. Ehud Gudes Security
Ch 2
RBAC0
המודל הבסיסי עליו מתבססיםשאר המודלים.
Users(U)
Roles(R)
Userassignment
(UA)
Permissionassignment
(PA) Permissions(P)
Sessions(S)
04/18/23Prof. Ehud Gudes Security
Ch 2
RBAC1
היררכייתRole.ים-
Users(U)
Roles(R)
Userassignment
(UA)
Permissionassignment
(PA) Permissions(P)
Sessions(S)
Role hierarchy(RH)
04/18/23Prof. Ehud Gudes Security
Ch 2
RBAC1
היררכיה שלRoleים-:
.קשר אב ובן.הרשאות אפקטיביות וישירות
Employee[Read]
Developer[Read,Develop]
QA[Read,Test]
Admin[Read,Test,Develop]
04/18/23Prof. Ehud Gudes Security
Ch 2
RBAC1
הגבלת ירושה.
Employee[Read]
Developer[Read,Develop]
QA[Read,Test]
Admin[Read,Test,Develop]
Developer'[Read,Develop,Build]
04/18/23Prof. Ehud Gudes Security
Ch 2
RBAC2
מודל האילוציםRole.ים מנוגדים-
Users(U)
Roles(R)
Userassignment
(UA)
Permissionassignment
(PA) Permissions(P)
Sessions(S)
Constranits
04/18/23Prof. Ehud Gudes Security
Ch 2
RBAC3
המודל המשולב: אילוצים והיררכייתRoles .
Users(U)
Roles(R)
Userassignment
(UA)
Permissionassignment
(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
04/18/23Prof. Ehud Gudes Security
Ch 2
המודל האדמיניסטרטיבי
בין -Roleהפרדה ל Roleרגילאדמיניסטרטיבי.
- ל משתמש .Roleהשמת
- ל הרשאה .Roleהשמת
השמתRole- .Roleל
04/18/23Prof. Ehud Gudes Security
Ch 2
-יםRoleהשמת משתמשים ל-
הענקתRole:למשתמש הגדרת תחומי אחריות שלRole אדמיניסטרטיבי על
.can_assignידי היחס
שלילתRole:ממשתמש הגדרת תחומי אחריות שלRole אדמיניסטרטיבי על
.can_revokeהיחס ידי – שלילה חלשהRole.אינו נשלל כתוצאה מירושה .שלילה חזקה – שלילת כל עץ הירושה
04/18/23Prof. Ehud Gudes Security
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
Top Related