Top Banner
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

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.

Dec 15, 2015

Download

Documents

Agustin Drover
Welcome message from author
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
Page 1: 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.

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

Page 2: 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.

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

Page 3: 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.

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.

Page 4: 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.

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.

Page 5: 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.

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.

Page 6: 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.

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.

Page 7: 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.

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.

Page 8: 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.

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

Page 9: 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.

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

Page 10: 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.

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.

Page 11: 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.

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

Page 12: 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.

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.

Page 13: 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.

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)

Page 14: 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.

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

Page 15: 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.

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)

Page 16: 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.

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)

Page 17: 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.

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.

Page 18: 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.

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)

Page 19: 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.

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.

Page 20: 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.

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

Page 21: 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.

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.

Page 22: 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.

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.

Page 23: 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.

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.

Page 24: 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.

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.

Page 25: 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.

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.

Page 26: 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.

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

Page 27: 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.

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.

Page 28: 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.

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.

Page 29: 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.

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)

Page 30: 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.

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

Page 31: 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.

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

Page 32: 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.

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

Secret (S), Confidential (C), Unclassified (U).– Categories (of subjects): e.g. Production,

Personnel, Engineering, Administration.

SC = (L,C) and SC’ = (L’,C’)

SC SC’ iff L L’ and C C’

Page 33: 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.

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.

Page 34: 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.

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.

Page 35: 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.

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.

Page 36: 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.

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.

Page 37: 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.

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

Page 38: 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.

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

Page 39: 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.

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.

Page 40: 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.

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.

Page 41: 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.

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.

Page 42: 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.

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

Page 43: 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.

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.

Page 44: 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.

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.

Page 45: 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.

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.

Page 46: 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.

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.

Page 47: 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.

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

Page 48: 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.

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.

Page 49: 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.

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

Page 50: 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.

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.

Page 51: 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.

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.

Page 52: 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.

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.

Page 53: 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.

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.

Page 54: 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.

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)

Page 55: 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.

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)

Page 56: 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.

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)

Page 57: 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.

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)

Page 58: 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.

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.

Page 59: 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.

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

Page 60: 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.

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.

Page 61: 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.

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.

Page 62: 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.

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.

Page 63: 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.

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

Page 64: 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.

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.

Page 65: 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.

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.

Page 66: 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.

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