Security models • The objective is to obtain a conceptual model of the desired security system. • There are many security models, covering one or more of the following: – OS security – DB security – mandatory or discretionary policy – focus on secrecy or integrity – protect direct access to information – protect flow or inference of information
66
Embed
Security models The objective is to obtain a conceptual model of the desired security system. There are many security models, covering one or more of the.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Security models• The objective is to obtain a conceptual
model of the desired security system.
• There are many security models, covering one or more of the following:– OS security– DB security– mandatory or discretionary policy– focus on secrecy or integrity– protect direct access to information– protect flow or inference of information
Harrison-Ruzzo-Ullmanaccess matrix model• The authorization state is defined using a
matrix correlating subjects, objects and authorizations.– S is a set of subjects (user, process or domain)– O is the set of objects, both passive entities (the
system resources) and active entities: the subjects. (Thus, )
– A is the access matrix. A[s,o] indicates the access modes for which subject s is authorized on object o.
O S
Harrison-Ruzzo-Ullman (cont.)• In the matrix each entry A[s,o] may be a
decision rule which specifies conditions on the access:– Data-dependent conditions: constraints on the
value of the accessed data.– Time-dependent conditions: the subject may
only access the object at certain times.– Context-dependent conditions: constraints on
the combinations of data which may be accessed.– History-dependent conditions: access depends
on previous actions by the same subject.
Harrison-Ruzzo-Ullman (cont.)• Access modes: what is the subject allowed to
do with the object?– read: subject may read values of object.– write: subject may update the object, thus erasing
previous values.– append: subject may add to the object, but not
erase any previous values.– execute: subject may execute the object (which
must be an application function).– own: subject owns the object and is thus allowed
to administer authorizations on the object.
Harrison-Ruzzo-Ullman (cont.)• Operations: there are six types of
operations on the access matrix.– Enter r into A[s,o]: subject s gets access right
r on object o.– Delete r from A[s,o]: access right r on object o
is revoked from subject s.– Create subject s: adds a new row and column
to A.– Delete subject s: deletes the row and column
corresponding to s.– Create object o: add a column to A.– Delete object o: delete o’s column from A.
Harrison-Ruzzo-Ullman (cont.)• Commands: consist of (first) a set of tests
(to see if the subject(s) have sufficient access rights on the object(s), followed by operations.
Example: if “owner” has O (owner) right of “file” then he revokes the R (read) right of subject “exfriend”.
command REVOKEread(owner,exfriend,file)
if O in A[owner,file]
then delete R from A[exfriend,file]
end.
Harrison-Ruzzo-Ullman (cont.)• Administration of authorizations: through
the “own” privilege subjects can administer authorizations on the objects they create.
(All rights except “own” can be transferred.)
If r is a right, A[s,o] can be r, r* or r+ for non-owners.– r means s cannot transfer the right.– r* indicates that s can transfer the right, but not
the copy flag *. (so recipients only receive r.)– r+ indicates that s can transfer the right, but then
loses it herself. + is the transfer flag.
Harrison-Ruzzo-Ullman (cont.)• Implementation of the access-matrix is not
straightforward:– bidimensional array: very memory-inefficient.– global table of triples: < s, o, A[s,o] >. (more
memory efficient, but it’s not directly visible which objects a subject can access or which subjects can access an object.)
– storing by rows: associate a list to each subject. elements are pairs < o, A[s,o] >. (A[s,o] non-null)
– storing by columns: associate a list to each object. elements are non-null pairs < s, A[s,o] >.
Harrison-Ruzzo-Ullman (cont.)• Expressiveness versus safety:
– Question: given an initial state, is there a reachable state in which a given subject S has a certain right on a given object O ?
– The authorization scheme constrains what harm a Trojan Horse program could do (because the reachable states are limited).
– In the HRU model the “safety question” is undecidable.
– Extensions to HRU exist to make the safety question decidable. (e.g. by disallowing “revoke”)
Take-Grant model• Extension to the access matrix model:
authorizations are represented through a graph structure.– (some) users are able to grant rights to others
in such a way that the recipient can also grant that right to others.
– (some) users are able to take rights on objects.– the process of revoking rights becomes more
complicated than in the plain access matrix model.
Take-Grant model (cont.)• Authorization state: (S, O, G) where
– S is a set of subjects.– O is a set of objects.– G is the graph describing the system
authorization state. The vertices are whereas .
– An arc means that x holds right r on y. (x is called the source node, and y is called the destination node.)
O S O S
yx r
Take-Grant model (cont.)• Access modes:
– Read: a “read” arc from A to B means that subject (or object) A may read object B.
– Write: a “write” arc from A to B means that subject (or object) A may write into object B.
– Take: a “take” arc from A to B means that A is allowed to take any right held by B on other subjects or objects in the system.
– Grant: a “grant” arc from A to B indicates that A can grant to B any of the rights A holds on other subjects or objects in the system.
Take-Grant model (cont.)• Operations and transfer of privileges:
– take(d,s,x,y): subject s takes right d on object or subject y from object or subject x. This requires that s holds the take (t) privilege upon x and x must hold the d privilege on y. After the op. both s and x hold privilege d on y. s sx x
yy
t t
d ddtake(d,s,x,y)
Take-Grant model (cont.)• Operations and transfer of privileges
(cont.):– grant(d,s,x,y): subject s grants right d on object or
subject y to object or subject x. This requires that s holds the grant (g) privilege on x and x must hold the d privilege on y. After the op. both s and x hold privilege d on y. s sx x
yy
g g
ddgrant(d,s,x,y)d
Take-Grant model (cont.)• Operations and transfer of privileges
(cont.):– create{subjectp|objectp}(s,x): subject s creates
object or subject x and is granted the set of rights p on x.s s x
pcreate subject p(s,x)
s s xpcreate object p(s,x)
Take-Grant model (cont.)• Operations and transfer of privileges
(cont.):– removep(s,x): subject s is revoked the p rights it
has (previously) been granted on object or subject x. When the result of this operation leaves s with no rights on x the arc from p to x is removed. s sx xe e-p
removep(s,x)
Take-Grant model (cont.)• Drawbacks of the take-grant model:
– Non-selectivity of administrative rights: the grant and take privileges are not limited to certain rights.
– No control on propagation of authorizations: when a subject grants a right to someone else he can not control further propagation of that right.
– Reversibility of the privileges transport flow: if rights can be transferred from x to y then the opposite flow of rights from y to x cannot be prevented.
Acten (Action-Entity) model• Extension to the Take-Grant model:
– New administrative privileges: (use, create, delete, ...)
– Predicates on authorizations: (conditions to be satisfied for access to be allowed)
– Representation using two graphs: (one for the authorizations for static actions and one for the authorizations for dynamic actions)
Acten (Action-Entity) model• Access modes:
– Use: typical for application programs: this right means the program can be executed.
– Read/Update/Create/Delete: access/modify an entity, or add/remove entities to/from the system.
– Grant/Revoke: the privilege allows an entity Ei to grant (resp. revoke) a static access mode m on an entity Ek to an entity Ej.
– Delegate/Abrogate: this privilege allows an entity Ei to grant (resp. revoke) the dynamic authorization grant related to access mode m on entity Ek to an entity Ej.
Acten (Action-Entity) model• Access modes and levels:
– Create/Delete 4– Update 3– Read 2– Use 1
• Administration rights and levels:– Delegate/Abrogate 2– Grant/Revoke 1
Acten (Action-Entity) model• Authorization for static access modes:
binary relation between entities, with access mode, direction and predicates.
Aij = a ~ {pij}
Entity Ei holds access right a on Ej if the conditions of pij are met.
• Authorization for dynamic access modes:
Aij/k = a ~ {pij}
Entity Ei may grant Ej the right to grant others access right a on entity Ek if pij is met.
Acten (Action-Entity) model• Authorization state Sa of entity Ei:
Sa(Ei) is the set of all authorizations Ei holds on all the other system entities.
• Protection state Sp of entity Ei:
Sp(Ei) is the set of all authorizations held by other system entities onto Ei.
Acten (Action-Entity) model• Classification of Entities:
– Active entity: if Sa(Ei) Ø. An active entity can execute some actions on some other system entities.
– Passive entity: if Sp(Ei) Ø. A passive entity is an entity that can undergo actions from other system entities.
– Active and Passive entity: if Sa(Ei) Ø and Sp(Ei) Ø. Such an entity can both execute and undergo actions.
Acten (Action-Entity) model• Two graphs:
– Static Graph SG: contains the authorizations for static actions (for read, update, ...).Arcs are labeled with (sets of) access modes.
– Dynamic Graph DG: contains the authorizations for dynamic actions (grant/revoke and delegate/abrogate).Arcs are labeled with tuples E, DA, SA, {M}:
• E is the entity to which the access refers,• DA is the dynamic action (e.g. grant),• SA is the static action (e.g. read),• M are the entities which can receive SA by delegation.
Acten (Action-Entity) model
E1 E2 E4
E5E3
Read
Read
Create/Delete
Update
Use
The X means that there is a condition.
Example of a static graph.
Acten (Action-Entity) model
E1 E2 E4
E8 E7
Grant read Grant use
Example of a dynamic graph.
E3 E5
E6
E6 Delegate update {10,9}
Grant read
Acten (Action-Entity) model• The model introduces two tables:
– Table of security classes. For each entity Ei:
• the highest level static action that Ei can execute on the system entities, or “active potentiality” of Ei.
• the lowest level dynamic action that can be executed by the system entities on Ei, or “passive potentiality” of Ei.
– Table of entity states. For each entity Ei that owns other entities the set of entities Ei owns.
Acten (Action-Entity) model• Constraints (rules) on the graphs:
– Internal consistency rules: The structure of SG and DG should be consistent with the structure, nature and security relationships of the represented protected system.
– Mutual consistency rules: SG and DG should be consistent in representing the privileges. (E.g. E cannot grant a privilege E does not hold.)
– Transformation rules: These control the indirect authorizations and the access right propagation.
Acten (Action-Entity) model• Internal consistency rules for SG:
– Only “sensible” access modes are allowed. (E.g. one cannot “delete” an I/O device.)
• Internal consistency rules for DG:– Only the owner of an entity can administer
authorizations on that entity.
– If Ej may grant an action of level L' on Ek to another entity then the owner of Ek can only delegate actions of level L > L'.
– (there are other rules)
Acten (Action-Entity) model• Mutual consistency rules for SG and DG:
– An entity must hold an access privilege in order to be allowed to administer this privilege.
– If an entity holds a static right of level L on entity Ek then it can only be granted static rights of level L' > L on Ek.
– The delegate and abrogate rights for access modes on an entity can only be executed by the owner of this entity. (The owner holds create/delete rights in SG.)
Discussion on discretionary models• Discretionary policies do not impose any
restriction on the usage of information once it is obtained by a user.
• This lack of “flow” control makes the system vulnerable for Trojan Horse attacks:– Suppose x has read access to object o1.
– Suppose y owns object o2 and program P.
– y can grant x write access to o2 and execute access to program P.
– When x executes P that program reads o1 and writes these data into o2. (y has now stolen o1.)
Bell-LaPadula model• Concentrates on information secrecy.
• Extension of the access matrix model.
• Uses security levels based on classification and categories:– Classification (of objects): Top Secret (TS),
Bell-LaPadula model (cont.)• Considers four access modes:
– Read-only: read the information in an object.– Append: append information to an object without
seeing its contents.– Execute: to execute a program.– Read-write: write into an object, while being
allowed to read it. (also called write for short)
• Users have a clearance: the security level assigned when creating the user.
• Users have a current level: a (possibly lower, never higher) level the user operates at.
Bell-LaPadula model (cont.)• axioms:
– Simple security (ss) property: A subject may have read or write access to an object only if the clearance of the user dominates the security level of the object.
This principle is only sufficient in environments where the users can be trusted. This means that the users will not attempt to compromise security, for instance by leaking confidential information to users with only access to unclassified information.
Bell-LaPadula model (cont.)• axioms (cont.):
– Star (*) property: An untrusted subject may have append access to an object if the security level of the object dominates the current security level of the subject. An untrusted subject may have write access to an object if the security level of the object is equal to the current security level of the subject. An untrusted subject may have read access to an object if the security level of the object is dominated by the current security level of the subject.
Bell-LaPadula model (cont.)• axioms (cont.):
Simple security and Star result in:– No read-up: A subject’s security level must
dominate that of objects it wants to read.– No write-down: A subject’s security level
must be dominated by that of objects it wants to write.
Note: A subject is allowed to write objects of a lower level than its clearance. It can only do this if it has not yet accessed objects at a higher level.
Bell-LaPadula model (cont.)• axioms (cont.):
– Discretionary security property (ds-property): A subject can exercise only accesses for which it has the necessary authorization. (This trivially says that the systems works according to the access rights that are defined.)
There are more axioms regarding active vs. inactive objects. (Active means created, and inactive means deleted.)
Biba model• Bell-LaPadula aims at secrecy by preventing
unauthorized release of information. However, it does not protect against unauthorized modifications of information.
• Biba aims at maintaining integrity. It considers the following access rights:– Modify: (write information in an object.)– Invoke: (invoke another subject, to communicate.)– Observe: (read information in an object.)– Execute: (execute an object which is a program.)
Biba model (cont.)• Biba does not provide grant and revoke
operations. (It does not specify a unique way to modify access rights.)
• Biba defines a family of security policies.– Non-discretionary policies:
Access rights are based on security levels. (Subjects cannot change access rights.)
– Discretionary policies: Access rights can be changed by subjects.
Biba model (cont.)Non-discretionary policies:• Low-watermark policy for subjects:
– A subject can hold the modify right to an object only if the integrity level of the subject dominates that of the object.
– A subject can hold the invoke right to another subject only if the integrity level of the first subject dominates that of the second subject.
– A subject can hold the observe right to any object. After an observe operation on an object the integrity level of the subject become the least upper bound of that of subject and object.
Biba model (cont.)Non-discretionary policies:• Low-watermark policy for objects:
– A subject can hold the modify right to objects at any integrity level. After each modification by a subject on an object the integrity level of the object is set equal to the greatest lower bound between the integrity level of the subject and that of the object (before the access).
This policy has a serious drawback: it allows improper modifications. High-integrity information can be irreversibly modified and “downgraded” to a lower integrity level.
Biba model (cont.)Non-discretionary policies:• Low-watermark integrity audit policy:
– A subject can hold the modify right to objects at any integrity level. If a subject modifies an object at higher or incomparable integrity level, the security violations are recorded in an audit trail.
This policy also allows improper modifications. It only makes such modifications “apparent”.
Biba model (cont.)Non-discretionary policies:• Ring policy: (integrity levels are fixed)
– A subject can hold the modify right to an object only if the integrity level of the subject dominates that of the object.
– A subject can hold the invoke right to another subject only if the integrity level of the first subject is dominated by the integrity level of the second subject.
– A subject can hold the observe right to objects at any integrity level.
Biba model (cont.)Non-discretionary policies:• Strict integrity policy:
– Integrity *-property: a subject can hold the modify right to an object only if the integrity level of the subject dominates that of the object.
– Invocation property: a subject can hold the invoke right to another subject only if the integrity level of the first subject dominates that of the second subject.
– Simple integrity condition: a subject can hold the observe right to an object only if the integrity level of the subject is dominated by that of the object.
Biba model (cont.)Non-discretionary policies:• Strict integrity policy: alternative definition
– No Read-Down Integrity: A subject can only read objects whose integrity level dominates the integrity level of the subject.
– No Write-Up Integrity: A subject can only write objects whose integrity level is dominated by the integrity level of the subject.
This is the dual of the Bell-LaPadula model.
Biba model (cont.)Discretionary policies:• Access control lists:
– Each object is assigned an access control list indicating which subjects have which access rights on the object.
– The access control list of an object can be modified by subjects holding the modify right to the (object containing the) access control list.
Biba model (cont.)Discretionary policies:• Objects hierarchy:
– Objects are organized in a hierarchy (using a rooted tree structure).
– To access an object a subject must have observe access to all the object’s ancestors (i.e. all the objects on a path between the object and the root).
Biba model (cont.)Discretionary policies:• Ring: Each subject is assigned a privilege
attribute (called ring).– A subject can hold the modify right to objects
only in an allowed range of rings.– A subject can hold the invoke right to subjects
of higher privilege rings only in an allowed range of rings. A subject can hold the invoke right to any subject with lower or equal privilege ring.
– A subject can hold the observe right to objects only in an allowed range of rings.
Dion model• Dion combines principles of the Bell-
LaPadula modal and of the Biba model in order to protect secrecy and integrity.
• Dion does not provide discretionary policies, only a mandatory policy.
• Dion does not allow information transfer from objects to subjects. Information flows directly between objects through connections. (A subject creates a directed connection between objects.)
Dion model (cont.)• Classification of subjects:
– Absolute Security Level (ASL): fixed security level of the subject, given at its creation.
– Read Security Level (RSL): highest security level from which the subject is allowed to read.
– Write Security Level (WSL): lowest security level to which the subject is allowed to write.
– Absolute Integrity Level (AIL): fixed integrity level of the subject, given at its creation.
– Read Integrity Level (RIL): lowest integrity level from which the subject is allowed to read.
– Write Integrity Level (WIL): highest integrity level to which the subject is allowed to write.
Dion model (cont.)• Classification of objects:
– Absolute Security Level (ASL): fixed security level of the data in the object.
– Migration Security Level (MSL): highest security level to which data in object may flow.
– Corruption Security Level (CSL): lowest security level from which data may flow into object.
– Absolute Integrity Level (AIL): fixed integrity level of the data in the object.
– Migration Integrity Level (RIL): lowest integrity level to which data in object may flow.
– Corruption Integrity Level (CIL): highest integrity level from which data may flow into object.
Dion model (cont.)• axioms:
– Migration property: The migration levels of the object being written to (o2) must be at least as restrictive as those of the object being read (o1).
MSL(o1) MSL(o2)
MIL(o1) MIL(o2)
This ensures that the migration, security and integrity levels of o1 will not be circumvented.
Dion model (cont.)• axioms (cont.):
– Corruption property: The corruption levels of the object being read (o1) must be at least as restrictive as those of the object being written (o2).
CSL(o1) CSL(o2)
CIL(o1) CIL(o2)
This ensures that the corruption, security and integrity levels of o2 will not be circumvented.
Dion model (cont.)• axioms (cont.):
– Security property: The subject establishing the connection must have read access to the object being read (o1) and write access to the object being written (o2). The read security level of the subject must dominate the absolute security level of the object being read (o1). The write security level of the subject must be dominated by the absolute security level of the object being written (o2).
RSL(s) ASL(o1)
WSL(s) ASL(o2)
Dion model (cont.)• axioms (cont.):
– Integrity property: The subject establishing the connection must have read access to the object being read (o1) and write access to the object being written (o2). The read integrity level of the subject must be dominated by the absolute integrity level of the object being read (o1). The write integrity level of the subject must dominate the absolute integrity level of the object being written (o2).
RIL(s) AIL(o1)
WIL(s) AIL(o2)
Dion model (cont.)• axioms (cont.):
– Write/corruption property: The absolute security level of the subject must dominate the corruption security level of the object being written (o2). The absolute integrity level of the subject must be dominated by the corruption integrity level of the object being written (o2).
ASL(s) CSL(o2)
AIL(s) CIL(o2)
Dion model (cont.)• axioms (cont.):
– Read/migration property: The absolute security level of the subject must be dominated by the migration security level of the object being read (o1). The absolute integrity level of the subject must dominate the migration integrity level of the object being read (o1).
ASL(s) MSL(o1)
AIL(s) MIL(o1)
The Sea View model• Used in a relational database system
developed at Stanford Research Institute.
• Consists of two layers:– MAC: Mandatory Access Control
This layer corresponds to the mandatory security policies of the Bell-LaPadula and Biba models.
– TCB: Trusted Computing Base Defines the concept of multilevel relations, supporting discretionary controls for multilevel relations and views, and formalizes the supporting policies. TCB is built on top of MAC.
The Sea View model (cont.)• Multilevel relations
– For each data attribute Ai there is a classification attribute Ci.
– For each tuple there is an (overall) classification attribute value (TC).
Name Cname Dept Cdept TC
Bob S Dept1 S S
Ann S Dept2 TS S
Sam TS Dept3 TS TS
The Sea View model (cont.)• axioms:
– Database class integrity: The access class of a relation scheme must dominate the access class of the name of the database to which it belongs.
– Visible data property: The access class of a relation scheme must be dominated by the access class of the lowest data that can be stored in the relation.
– View class integrity: The access class of a view definition must dominate the access class of any relation or view named in the view definition.
The Sea View model (cont.)• axioms (cont.):
– Multilevel entity integrity: The classification attributes Ci corresponding to data attributes Ai that belong to the primary key of a relation R must all have the same value within a tuple. The values for classification attributes for other attributes must dominate the values for the classification attributes of the primary key within the same tuple.
Thus, the primary key is the least secret part of a tuple and has the highest integrity.
The Sea View model (cont.)• axioms (cont.):
– Multilevel referential integrity: Within a tuple, the access class of each element comprising a secondary key must be the same and must dominate the access class of the primary key element(s) in the tuple referenced.
Thus, if a foreign key is visible, then the tuple containing the referenced primary key must also be visible at that access class.
The Sea View model (cont.)• axioms (cont.):
– Polyinstantiation integrity: There is a functional dependency from the primary key (including the classification and data attributes) and the i-th classification attribute to the i-th data attribute.
There is a multivalued dependency from the primary key to the i-th element class and value.
AK,CK,Ci Ai
AK,CK Ai,Ci
The Sea View model (cont.)• Maintaining secrecy and integrity:
the need for polyinstantiation– The subject clearance is dominated by (or
incomparable with) the access class of the data.
Inserting data into a relation, when “conflicting” data already exists at a higher class, must be accepted silently, in order to not reveal the existence of the conflicting data.
Such an insertion generates polyinstantiation.
The Sea View model (cont.)• Maintaining secrecy and integrity:
the need for polyinstantiation– The subject clearance dominates the access
class of the data.
Inserting a tuple with the same primary key as an existing tuple with a lower access class can be executed.
In order to not reveal the update to users who can only view the lower access class the old tuple cannot be deleted.
Thus, this update generates polyinstantiation.
Discussion on mandatory models• Mandatory models are suitable when users
and objects can be classified.
• They allow to track the flow of information, thus protecting against Trojan Horse attacks.
• Mandatory models are rigid. They can be difficult to use in “commercial” environments. (A combined model like Sea View may be more suitable.)