Opera Group Meeting, May 11th, 2004. Talk Outline

1
A Formal Model for Hierarchical Policy Contexts

• Opera Group Meeting, May 11th, 2004

2
Talk Outline

• Motivation and Background.
• Role-Based Access Control.
• RBAC Policy Representation.
• Difficulties in large-scale policy
  administration.
• Policy Contexts.
• Where we were last year.
• Overview of our hierachical context formal model.
• Managing information flow.
• OASIS RBAC policy components.
• Access control to policies themselves.
• Future Work.
• Conclusion.

3
Background

• Role-Based Access Control
• Simplifies security management by introducing the
  role abstraction between principals and
  privileges.
• Access control policy is authored via
• some static relations (simple).
• rules which involve policy inferencing (more
  complex).
• Large-scale policy administration
• Real deployments of RBAC require large numbers of
  roles.
• Role parameterisation can reduce explosive
  growth.
• A student role parameterised by their ID, for
  example.
• Not possible to perform centralised
  administration
• A commonly used example UK National Health
  Service.

4
Policy Contexts

• Policy Contexts were introduced last year at
  Policy.
• Provide a labelling mechanism for RBAC
  components.
• Operates in parallel with RBAC rule semantics.
• Focuses on policy administration not system
  operation.
• Our work used OASIS RBAC as its basis.
• Open Architecture for Secure Interworking
  Services.
• Rules, roles, and parameters are the main policy
  elements.
• Contexts introduces Mandatory Access Control
  properties
• In particular information flow constraints.
• We discussed how labelling also helps policy
  administration.
• Extending our initial work
• We provide a formal model.
• Define hierarchical context management.

5
Parallel context classification

• Consider a parallel information flow example
• The left models the human hierarchy of an
  organisation.
• The right models an aspect of implementation.
• We wish to enforce both sets of constraints
  simultaneously.
• We need some formal semantics to make sense of
  this.

6
Non-hierarchical Contexts

• A non-hierarchical context is a finite set of
  labels.
• Each label is a context element (CE).
• We define an information flow relation A A B
• i.e. flow is permitted from context element A to
  element B.
• Wildcard support is desirable for
  future-proofing
• Allow future rules to be included under existing
  restrictions.
• Wildcards require scoping to avoid security
  problems.
• We need to support parallel information flow
  specifications.
• Grouping labels which themselves represent
  contexts provides a solution to the scoping
  problem.
• Hence our introduction of hierarchical contexts.

7
Hierarchical Contexts (2)

• Allow administration on numerous levels.
• Contexts on at a given level become
  context-elements in the next level down the
  hierarchy.

8
Hierarchical Contexts (3)

• Let C be the set of all hierarchical context
  elements.
• First we define the parent relationship
• ?X?C, context element X has at most one direct
  parent P.
• We define Cparent as the relation (P,X) ?
  Cparent
• We further require that CEs cannot be their own
  parent.
• Thus (C,Cparent) forms a forest of rooted trees.
• The Croot predicate evaluates true for root
  CEs.
• We require that labels are unique among siblings
• This means that root CE labels must also be
  unique.
• We introduce a path notation on CE labels
• For example CompLab.OPERA.Middleware

9
Hierarchical Contexts (4)

• Wildcards are defined using parameterised
  symbols.
• For example subtree(X) indicates an information
  source or target for X and the entire sub-tree of
  which it is the root.
• All parameterised symbols are belong to the set
  CE
• At enforcement time, expand is the function used
  to generate all CE members from C given an
  element from CE
• We also maintain E to mean all context elements.
• Information flows are specified via two
  functions
• context_out C ? P(C ? CE ? E)
• context_in C ? P(C ? CE ? E,e)
• Here P represents a power-set.
• Also e indicates an initial context element.
• Initial CEs imply no information flow checks are
  done.

10
Information flow

• The information flow graph will contain an edge
  between two context elements if both elements in
  and out restrictions are satisfied.
• We need Ceval to generate a set of elements from
  expressions, e.g. with respect to our earlier
  figureCeval(CompLab.Security,
  subtree(CompLab.OPERA)) CompLab.Security,
  CompLab.OPERA, CompLab.OPERA.general,
  CompLab.OPERA.Trust, CompLab.OPERA.Policy,
  CompLab.OPERA.Middleware
• So we can define the relation A A B ? (AB)
  ?(B?Ceval(context_out(A)) ? A?Ceval(context_in(B)
  ))
• Also define A as the transitive closure of
  direct edges.

11
Information flow in practice

• For information to flow between a parent and a
  child both the childs in and the parents out
  information flow restrictions must be considered
  (or vice versa).
• Either explicit context element definitions are
  used,
• or appropriate wild-card expressions can be
  employed.
• Wild-cards are intended to assist future-proofing
  through use of abstractions instead of explicit
  labels.
• Another consideration is that context elements in
  an information-flow cycle end up being
  equivalent.
• This could lead to unintuitive results.
• Such context elements may still be usefully kept
  separate for non-information flow context
  purposes however.

12
Policy management

• Note that policy components are associated with
  contexts rather than context elements.
• i.e. components may have multiple context element
  labels.
• This increases the expressive power of context
  constraints.
• We can encode multiple parallel constraint
  dimensions.
• Information flow between contexts A ? P(C) ?
  P(C)
• Consider a A b
• Each context element in a must reach (via A) one
  in b.
• Almost the same applies for context elements in b
  all being reached (again via A) by those in a
  except
• B in b might be initial (i.e. have e ?
  context_in(B)).
• Details are in the paper (see Definition 3.1)

13
OASIS policy rules

• OASIS has a particular structure for its policy
  rules
• Privilege Authorisation r, e1, , ene H p
• Role Activation r1, , rnr, ac1, , acnac, e1,
  , ene H r
• All components may be annotated with contexts.
• Also any rule component may have subcomponents
  which are classified into contexts
  rule_compcontextcomp(param1context1,paramncon
  textn)
• Parameterised attributes need context labelling
  when being handled by certain predicates.
• They may have different sensitivities.
• For example a patient identifier versus a simple
  date field.
• External predicates facilitate information flow
  in and out of the access control software.

14
Managing access control to policies

• Through labelling, contexts provide a means to
  view and categorise the policy rules themselves.
• Encode structural groups.
• Even without information flow this may help
  identify individual ward rules within a hospital
  policy.
• Note that sub-components of a policy component
  must belong to the context of their parent
  however
• This simplifies administration and increases
  safety - this localises the effects of the
  context in and out functions, whilst not
  precluding expressive context flow mappings.
• Provide a target for administrative privileges.
• Visibility of policy rules to different
  principals.
• Organisational versus functional roles.
• Contexts can indicate role properties to policy
  designers.

15
Future work

• Using contexts to manage audit granularity.
• Certain contexts may indicate greater logging
  interest.
• Classify remote credential sensitivity.
• Certain credentials may need faster revocation
  checks.
• Context support for dynamic constraints.
• Grouping for cardinality constraints.
• Dynamic separation of duties is an example.
• Integration into other RBAC systems.
• NIST RBAC schemes are simpler than OASIS
• Need to consider interactions with
  role-hierachies however.
• Ponder hierarchical management domains similar
• Introduce explicit information flow restrictions.

16
Conclusion

• We have introduced hierarchical policy contexts
  to facilitate enforcement of information flow
  constraints during policy specification.
• Extended our earlier work with a formal model.
• We applied our context research to the OASIS RBAC
  system, but it is intended to generalise cleanly.
• We also discussed other useful context functions
• Management of access control to the policies
  themselves.
• Contexts add another level to policy authoring.
• We feel the benefits in large-scale policy
  systems will outweigh this extra complexity.
• Any questions?