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 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
Security models are database and operating system independent.
Some of these models can be (at least partially) realized using off the shelf database management systems while others cannot.

2. Harrison-Ruzzo-Ullman access 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.
A domain is defined as the context or protection environment inside which a process operates. A process may be associated to different domains during its execution, therefore it may hold different privileges.

3. 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.
Data dependent: a user may for instance only be allowed to access employee records for employees with a salary less than X.
Time-dependent: a user may only access the employee records between 8.00am and 5.00pm.
Context dependent: a user may be authorized to read names of employees, salaries of employees, but not employee-name and salary together in order to see who has which salary.
History-dependent: a user may be authorized to read salaries only if he has not previously read the names of the employees. (If they normally appear in the same order he would be able to form pairs after all.)

4. 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.
Some versions of the model also consider the mode control.
This is meant for systems where processes can spawn subprocesses.
A process that spawns a subprocess gets the control access mode over that subprocess.

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

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

7. 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.
The copy flag and transfer flag are a bit confusing, because they only apply to non-owners. This means that in order to determine whether a subject can transfer a right one must not only look at that right and the flags, but also look at the ownership.

8. 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] >.
Storing by rows makes it easy to find the objects which a given subject can access, but difficult to find the subjects who can access a given object.
For storing by columns the difficulty is the other way around.

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

10. 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.
The Take-Grant model is an extension to the access matrix model.
In HRU one can only give grants, and not take them.

11. 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.)
Note that objects may hold certain rights on other objects.
(An object may for instance be allowed to read another object.)

12. 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.
The first two: read and write, are called inert in that they do not modify the system authorization state.
The last two, by allowing right transfer and therefore graph modification, are called transport rights.
Take and grant rights can be held only by subjects. Read and write rights can be held by subjects and objects.
note: the take and grant rights can also be transferred. it is thus possible to grant others the right to grant someone any rights.
If A holds the grant right to B and C, A can grant B the grant right to C.
This means that A grants B the right to transfer all its (B’s) rights to C.

13. 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 x s x t t
In this graphical representation the black dots represent subjects and the grey dots represent subjects or objects. d d
take(d,s,x,y) d y y

14. 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 x s x g g d d
grant(d,s,x,y) d y y

15. 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
create subject p(s,x) p s s x
create object p(s,x) p

16. 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 x
removep(s,x) s x e
e-p
After this viewgraph you might want to turn to page 55 of the book to give the example there.

17. 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.
Non-selectivity: if X can grant to Y he can grant any privilege to Y. One would like to have a restriction that X can only grant read privilege to Y.
No control on propagation of authorizations:
When A has read access on X, and A has grant access on B and B has grant access on C, the A can transfer the X right to B but cannot prevent B from granting this right to C.
Also, when A has read access on X, and B has take access on A, B can take the read access on X, and transfer it to others it has a grant right on, or others who have take right on B can take the read right on X from B.

18. 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)
All these concepts are explained on the following sheets.
“static actions” are create, read, write, delete, ...
“dynamic actions” are grant, revoke, ...

19. 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.
Grant means that a user can grant access to an object to someone else.
Delegate means that a user can grant someone else the right to grant an access right to others.
If someone has create/delete privileges and delegate/abrogate privileges on an entity then he is said to be the owner of that entity.
NOTE: a further “refinement” is that for the Delegate/Abrogate privileges one can also specify that Ej only receives the right to grant access m on Ek to specific entities. This appears a few viewgraphs later.

20. 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
In the Acten model if one has an access mode right of level L then one also has the rights of levels L’ < L. And if one has the administration right of level L then one also has the administration right of level L’ < L.

21. 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.
These authorization relations are used on the next viewgraph to define the authorization state.
The conditions are system conditions like time or origin location of a request or other conditions that can be evaluated externally to the requested data.
Data dependent conditions must be “simulated” by creating new entities. If a user is authorized to read only salaries below X then two tables must be created: one with salaries below X and one with salaries above X and the user then gets access to only the first table.

22. 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.
On page 62/63 a somewhat complicated expression of Sa and Sp is given.

23. 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.
A “file” is a typical passive entity.
A “dba” or “root” is a typical active entity.
Normal users are typically active and passive.

24. 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.
Following sheets contain example graphs.

25. Acten (Action-Entity) model
Read
Update E1 E2 E4
The X means that there is a condition.
Read
Use
Create/Delete E5 E3
On page 64 a legend for this graph is given:
E1 is a user
E2 is an application
E3 is a peripheral
E4 is a data record
E5 is an application
E13 is use~{p} where {p} is “from 8 am to 12 am”
Thus, the user can invoke applications E2 and E5 that manipulate E4.
He can access peripheral E3 only in the morning.
Example of a static graph.

26. Acten (Action-Entity) model
Grant read
Grant use E1 E2 E4 E6
Delegate update {10,9} E8 E7
Grant read E6
Legend (page 64)
E1, E2 and E9 are users
E3 is a data file
E4, E7, E8 and E10 are applications
E5 is an I/O device
E6 is a data field
a12/3 is grant read~{p} and {p} is “if E2 belongs to project P
The arc between E2 and E7 means that E2 can transfer to E7 the grant privilege for the update access mode upon E6; it also shows that E7 can further transfer this privilege to entities E9 and E10.
Example of a dynamic graph.

27. 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.
The table of security classes allows the administrators to assign an authority level and a protection level to each system entity according to its physical nature and its functional position in the system, or according tot the role played by an entity within a project or in the organization.
The table of entity states can be examined to verify the legitimacy of requests of grant/revocation of dynamic actions. In fact, these requests can be authorized only to the owner of the entity to which the involved access mode is referred.

28. 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.
These rules are explained in the following sheets!

29. 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)
See pages 66/67
SG: For a “file”, “use” must be interpreted. It can for instance mean “execute” without “read” or “write” access.
DG:
Only the owner can delegate.
After delegating something one can only delegate more. -

30. 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.)
Actually, the formal definition says that the first entity must hold access privileges of at least the same level as the one it wants to grant to someone else.
The second rule is similar to the second internal consistency rule for DG.

31. 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.)
A user who has “read” access to an object can read the object and then pass the data on to users who do not have read access.
The Trojan Horse example illustrates this well.
The following models are “mandatory” models.
They are explicitly intended to provide a defense against such Trojan Horse attacks.
They concentrate on integrity, secrecy or both.

32. 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’
Discretionary models concentrate on information integrity, whereas mandatory models concentrate on information secrecy.
As we saw before, a lower security level means that a smaller group has access to a lower classification of object.

33. 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.
Sometimes the names are different: Read-write may be called “write”.
“Append” is also a bit of a restrictive name for writing in general, without being allowed to read.

34. 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.
Clearly, the trojan horse attacks are not prevented through this axiom.

35. 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.
Example: Jim (confidential) must be able to read an unclassified document by me in order to evaluate a salary decision (confidential).
According to the simple security axiom Jim would be allowed to write the decision in a public document. A trusted user Jim would not do this.
According to the Star axiom an untrusted user Jim is not allowed to write anything in an unclassified document. This effectively prevents Jim from making the confidential salary decision public.

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

37. 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.)
The rules for active/inactive objects say:
Tranquillity principle: this rule has been abandoned. It says that the classification of an active object cannot be changed. This thus means that when an object is created it must be assigned a classification and that cannot be changed later.
Non-accessibility of inactive objects: objects that have not been created or that have been deleted cannot be accessed (no subject can have read or write access rights on them).
Rewriting of inactive objects: the initial value of an object that is created (activated) is independent of the value of that object during previous activations. Thus, when an object is deleted and later it is recreated, the previous content is lost.

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

39. 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.
The families of security policies are explained on the following sheets.
Each security policy is independent of the others. Biba is thus able to describe more and less secure systems.

40. 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.
This policy is dynamic: the integrity level of a subject possibly decreases the integrity level of a subject upon each observe operation on objects with lower or incomparable integrity levels. This is a problem: the integrity level of a subject depends on the order in which operations are executed. Some orders may lead to failure because the subject has sabotaged its own access rights.
But this policy may also lead to increased integrity levels of a subject. Once a subject observes an object at a higher integrity level it also gets a higher integrity. After doing that it can get access rights which it cannot hold at its original integrity level.

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

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

43. 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.
Note that the second requirement is the inverse of that of the low-watermark policy for subjects.
A high-level subject can observe a low-level object and modify it.
Hence, information can flow from low to higher or incomparable integrity levels.
A subject thus needs to be cautious when using data from a lower-integrity object.

44. 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.
Note that this is the dual of the Bell-LaPadula policy for the integrity problem.
The strict integrity policy prevents information from being transferred from low-integrity objects to objects at higher or incomparable integrity levels, assuming that information flow results only from observe and modify accesses.

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

46. 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.
Again, there are three different possible policies (that more or less exclude each other).
The “modify right to the access control list” thus says that in fact for each object there are two objects: the object itself and an administration object containing the access rights to the object.

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

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

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

50. 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.
For each subject s the following must hold:
WSL(s)  ASL(s)  RSL(s)
RIL(s)  AIL(s)  WIL(s)

51. 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.
For each object the following must hold:
CSL(o)  ASL(o)  MSL(o)
MIL(o)  AIL(o)  CIL(o)

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

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

54. 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)
This property corresponds to the No Read-Up and No Write-Down secrecy of the Bell-LaPadula model.

55. 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)
This corresponds to the No Read-Down and No Write-Up integrity of the strict integrity policy of the Biba model.

56. 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)
This property guarantees the satisfaction of the corruption levels of the object to which information is transferred with respect to the subject making the connection.

57. 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)
This property guarantees the satisfaction of the migration levels of the object from which information is transferred with respect to the subject making the connection.

58. 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.
SeaView stems from SEcure dAta VIEW.
Because MAC is based on Bell-LaPadula we are not elaborating it here.

59. 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 Dept S S
Ann S Dept TS S
Sam TS Dept TS TS

60. 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 access class has a secrecy component and an integrity component.
This corresponds to the Bell LaPadula and Biba models.
An access class dominates another if it has higher secrecy and lower integrity.
If the database class integrity would not hold then relations with a class lower than the class of the database name would not be available to users at an access class lower than the class of the database.
Indeed, if the database is more secret than the relation, users at the level of the relation would not be able to access the relation because they could not access the database.
The reason for the visible data property is similar: if the relation were more secret than the data in it, users at the level of some of the data would not be able to access the relation.
There is an addition to the visible data property:
The greatest lower bound of the range of access classes specified for an attribute must dominate the access class of the relation scheme.

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

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

63. 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
Polyinstantiation means that there may be different tuples with the same primary key, but with different access classes.

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

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

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