Security models

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

2
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. As,o indicates the
  access modes for which subject s is authorized on
  object o.

3
Harrison-Ruzzo-Ullman (cont.)

• In the matrix each entry As,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.

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.

5
Harrison-Ruzzo-Ullman (cont.)

• Operations there are six types of operations on
  the access matrix.
• Enter r into As,o subject s gets access right
  r on object o.
• Delete r from As,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 os 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 Aowner,file
• then delete R from Aexfriend,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, As,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.

8
Harrison-Ruzzo-Ullman (cont.)

• Implementation of the access-matrix is not
  straightforward
• bidimensional array very memory-inefficient.
• global table of triples lt s, o, As,o gt. (more
  memory efficient, but its 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 lt o, As,o gt.
  (As,o non-null)
• storing by columns associate a list to each
  object. elements are non-null pairs lt s, As,o gt.

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.

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

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.

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
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
grant(d,s,x,y)
d
d
y
y
15
Take-Grant model (cont.)

• Operations and transfer of privileges (cont.)
• createsubjectpobjectp(s,x) subject s creates
  object or subject x and is granted the set of
  rights p on x.

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

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)

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.

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

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.

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.

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.

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.

25
Acten (Action-Entity) model
Read
Update
E1
E2
E4
The X means that there is a condition.
Read
Create/Delete
Use
E5
E3
Example of a static graph.
26
Acten (Action-Entity) model
E3
E5
Grant read
Grant use
E1
E2
E4
E6
Delegate update 10,9
E8
E7
Grant read
E6
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.

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.

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 gt L'.
• (there are other rules)

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

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

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

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.

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.

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.

36
Bell-LaPadula model (cont.)

• axioms (cont.)
• Simple security and Star result in
• No read-up A subjects security level must
  dominate that of objects it wants to read.
• No write-down A subjects 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.)

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.

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.

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.

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.

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.

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

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.

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)

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)

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)

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)

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.

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 Dept1 S S
• Ann S Dept2 TS S
• Sam TS Dept3 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.

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

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