Access Control (slides based Ch. 4 Gollmann)

1
Access Control(slides based Ch. 4 Gollmann)
2
Preliminary Remarks

• Computer systems and their use have changed over
  the last three decades.
• Traditional multi-user systems provide generic
  services to their users and do not know about
  the meaning of files they handle.
• PC systems support individual users in their
  jobs. Access operations are complex and
  application specific. Users are not interested in
  the details of how their programs are executed.

3
Preliminary Remarks

• This lecture will look at the access control
  (authorization) part of computer security.
• Traditional access control as found in
  operating systems like Windows or Unix.
• Cover the concepts typically used in defining
  automated security policies at that level.
• Keep in mind that these concepts were developed
  to support organizational policies in closed
  organizations (enterprises).

4
Authentication Access Control
B. Lampson, M. Abadi, M. Burrows, E. Wobber
Authentication in Distributed Systems Theory and
Practice, ACM Transactions on Computer Systems,
10(4), pages 265-310, 1992
5
authorization

• An active entity, called principal or
  subject, requests access to a passive entity,
  called object.
• authorization The reference monitor decides
  whether access is granted or denied.
• The reference monitor has to find and evaluate
  the (automated) security policy relevant for the
  current request.
• User identities are one of the parameters
  considered in security policies.

6
Principals and Subjects

• Principal and subject are both used to denote
  the active entity in an access operation.
• The word principal has many different meanings
  and is the source of much confusion.
• Subjects operate on behalf of human users we call
  principals, and access is based on the
  principals name bound to the subject in some
  unforgeable manner at authentication time.
• Because access control structures identify
  principals, it is important that principal names
  be globally unique, human-readable and memorable,
  easily and reliably associated with known people.
  M. Gasser, 1990

7
Gollmanns Recommendation

• Policy A principal is an entity that can be
  granted access to objects or can make statements
  affecting access control decisions.
• Example a user ID
• System Subjects operate on behalf of (human
  users we call) principals access is based on the
  principals name bound to the subject in some
  unforgeable manner at authentication time.
• Example a process (running under a user ID)

8
Basic Terminology

• Subject/Principal active entity user or
  process.
• Object passive entity file or resource.
• Access operations vary from basic memory access
  (read, write) to method calls in an
  object-oriented system.
• Comparable systems may use different access
  operations or attach different meanings to
  operations which appear to be the same.

9
Approaches to authorization

• Subjects and objects provide a different focus of
  control (first design principle)
• What is the principal allowed to do?
• What may be done with an object?
• Traditionally, multi-user operating systems
  manage files and resources, i.e. objects access
  control takes the second approach.
• Application oriented IT systems, like database
  management systems, direct services to the user
  and often control actions of principals.

10
Access Operations

• On the most elementary level, a subject may
• observe an object, or
• alter an object.
• With these basic access modes we can express some
  fundamental policies.
• For practical purposes a richer set of operations
  is more convenient.
• We will give a few examples for richer sets of
  access operations note how certain terms are
  used with different meanings.

11
Elementary Access Operations

• The Bell-LaPadula model (to be covered) has four
  access rights
• execute
• read
• append, also called blind write
• write
• Mapping between access rights and access modes.

12
Rationale

• In a multi-user O/S, users open files to get
  access. Files are opened for read or for write
  access so that the O/S can avoid conflicts like
  two users simultaneously writing to the same
  file.
• Write access usually includes read access. A user
  editing a file should not be asked to open it
  twice. Hence, the write right includes observe
  and alter mode.
• Few systems implement append. Allowing users to
  alter an object without observing its content is
  rarely useful (exception audit log).
• A file can be used without being opened (read).
  Example use of a cryptographic key. This can be
  expressed by an execute right that includes
  neither observe nor alter mode.

13
Multics
Multics has access attributes for data segments
and access attributes for directory segments the
access attributes are given with their mapping
onto the Bell-LaPadula access rights e, r, a, w

• Data segments
• read r
• execute e, r
• read and write w
• write a

• Directory segments
• status r
• search e
• status modify w
• append a

14
Unix

• Access operations applied to a directory
• read list contents
• write create or rename files in the directory
• execute search directory

• Three access operations
• read from a file
• write to a file
• execute a file

These operations differ from the Bell-LaPadula
model. Unix write access does not imply read
access. Moral Do not use your own intuition when
interpreting access operations someone else has
defined!
15
More Access Rights

• Policies for creating and deleting files can be
  expressed by
• access controls on the directory (Unix)
• specific create and delete rights (Windows,
  OpenVMS)
• Policies for defining security settings such as
  access rights could be handled similarly
• access control on the directory
• specific rights like grant and revoke
• Rights in CORBA get, set, use, manage

16
Who Sets the Policy?
Security policies specify how principals are
given access to objects. Two options for deciding
who is in charge of setting the policy

• The owner of a resource decrees who is allowed
  access. Such policies are called discretionary as
  access control is at the owners discretion.
• A system wide policy decrees who is allowed
  access. Such policies are called mandatory.

Warning There exist other interpretations of
discretionary and mandatory.
17
Access Control Structures

• Requirements on access control structures
• The access control structure should help to
  express your desired access control policy.
• You should be able to check that your policy has
  been captured correctly.
• Access rights can be defined individually for
  each combination of subject and object.
• For large numbers of subjects and objects, such
  structures are cumbersome to manage. Intermediate
  levels of control are preferable.

18
Access Control Matrix

• We specify for each combination of subject and
  object the operations that are permitted.
• S set of subjects
• O set of objects
• A set of access operations
• Access control matrix M (Mso)s?S,o?O
• The matrix entry Mso?A specifies the operations
  subject s may perform on object o.
• You can visualize the matrix as a (big) table.

19
Access Control Matrix

• When all your users (principals) are known
  individually, you can express your policy in an
  access control matrix, with a row for each
  principal and a column for each object

20
Access Control Matrix continued

• The access control matrix is
• an abstract concept,
• not very suitable for direct implementation,
• not very convenient for managing security.
• How do you answer the question Has your security
  policy been implemented correctly?
• Bell-LaPadula (Orange Book) access control
  matrix defines discretionary access control
  (DAC).
• Warning This use of discretionary differs from
  the one given some slides earlier.

21
Capabilities

• Focus on the subject
• access rights are stored with the subject
• capabilities ? rows of the access control matrix
• Subjects may grant rights to other subjects.
  Subjects may grant the right to grant rights.
• How to check who may access a specific object?
• How to revoke a capability?
• Distributed system security has created renewed
  interest in capabilities.

Alice
edit.exe exec
fun.com exec,read
22
Access Control Lists (ACLs)

• Focus on the object
• access rights are stored with the object.
• ACLs ? columns of the access control matrix.
• How to check access rights of a specific subject?
• ACLs are implemented in most commercial operating
  systems but their actual use is limited.
• Referring to individual users in a policy works
  best within organisations.
• A management overhead has to be paid.

23
Groups

• Alice and Bob are students in a large class the
  lecturer wants to give students access to some
  documents
• Entering all names into several ACLs is tedious
  so the lecturer defines a group, declares the
  students to be members of the group, and puts the
  group into the ACLs
• Access rights are often defined for groups
• Unix owner, group, others

24
Groups Negative Permissions

• Groups are an intermediate layer between users
  and objects.
• To deal with special cases, negative permissions
  withdraw rights

25
Roles

• Alternatively, in our example we could have
  created a role student.
• Definition A role is a collection of procedures
  assigned to users a user can have more than one
  role and more than one user can have the same
  role.
• The lecturer would create a procedure for reading
  course material and assign this procedure to the
  role student.
• A role course tutor could be assigned a
  procedure for updating documents.

26
Role Based Access Control (RBAC)

• Procedures high level access operations with a
  more complex semantic than read or write
  procedures can only be applied to objects of
  certain data types.
• Example funds transfer between bank accounts.
• Roles are a good match for typical access control
  requirements in business.
• RBAC typical found at the application level.

27
More on RBAC

• We use intermediate levels of control to increase
  simplicity RBAC can also be used in ways that
  complicate matters
• Role hierarchies may refer to hierarchies of
  positions (superior subordinate) and to
  hierarchies of access rights these two
  hierarchies need not correspond.
• Separation of duties is an important security
  principle there are numerous flavours of static
  and dynamic separation of duties policies.

28
Role Based Access Control

• The term RBAC itself does not have a generally
  accepted meaning, and it is used in different
  ways by different vendors and users.
• R. Sandhu, D. Ferraiolo, and R. Kuhn The NIST
  Model for Role-Based Access Control Towards a
  Unified Standard, Proceedings of the 5th ACM
  Workshop on Role-Based Access Control, Berlin,
  Germany, July 26-27, 2000

29
Intermediate Controls
Intermediate controls facilitate better security
management. To deal with complexity, introduce
more levels of indirection.
30
Intermediate Controls

• Several intermediate concepts can be inserted
  between subjects and objects
• Roles collection of procedures assigned to
  users.
• Procedures high level access control methods
  with a more complex semantic than read or write
  procedures can only be applied to objects of
  certain data types.
• Data types each object is of a certain data type
  and can be accessed only through procedures
  defined for this data type.

31
Protection Rings

• Each subject (process) and each object is
  assigned a number, depending on its importance,
  e.g.
• 0 operating system kernel
• 1 operating system
• 2 utilities
• 3 user processes
• These numbers correspond to concentric protection
  rings, with ring 0 in the centre giving the
  highest degree of protection.
• If a process is assigned the number i, then we
  say the process runs in ring i.
• Access control decisions are made by comparing
  the subjects and objects numbers.

32
Protection Rings
Protection rings are mainly used for integrity
protection.
33
Structuring Access Control

• Some resources in an academic department can be
  accessed by all students, other resources only by
  students in a particular year.
• The department creates groups like All-Students
  and Y1-Students.
• The two groups are related, Y1-Students is a
  subgroup of All-Students if All-Students has
  access to a resource, so has Y1-Students.
• There is no such direct relationship between
  Y1-Students and Y2-Students.

34
Partial Orderings

• We now can use comparisons in security policies
  Is the users group a subgroup of the group
  permitted to access this resource?
• Some groups are related but others are not (e.g.
  Y1-Students and Y2-Students).
• Relationships are transitive CS101-Students ?
  Y1-Students ? All-Students
• In mathematical terms, we are dealing with a
  partial ordering.

35
Mathematical Definition

• A partial ordering ? (less or equal) on a set L
  is relation on L?L that is
• reflexive for all a?L, a?a
• transitive for all a,b,c?L, if a?b and b?c, then
  a?c
• antisymmetric for all a,b?L, if a?b and b?a,
  then ab
• If a ? b, we say b dominates a or a is
  dominated by b.

36
Examples

• Integers with the relation divides by
• We can order 3 and 6 (3 divides 6) but we cannot
  order 4 and 6.
• Integers with the relation ? (less or equal)
• We can order any two elements (total ordering).
• Strings with the prefix relation
• We can order AA and AABC (AA is a prefix of AABC)
  but not AA and AB.
• Power set P(C) with the subset relation ?
• We can order a,b and a,b,c (a,b ? a,b,c)
  but not a,b and a,c.

37
Example VSTa Microkernel

• Groups in Unix are defined by their group ID and
  are not ordered
• VSTa uses (cap)abilities to support hierarchies
  VSTa (cap)ability is a list of integers .i1.i2.
  ??? .in , e.g. .1, .1.2, .1.2.3, .4, .10.0.0.5
  
• Abilities are ordered by the prefix relation
• a2 is a prefix of a1 (written as a2 ? a1) if
  there exists a3 so that a1 a2a3
• The empty string ? is the prefix of any ability
• For example .1 ? .1.2 ? .1.2.4 but not .1 ? .4 !

38
Abilities and our Example

• Assign abilities to groups
• All-students .3
• Y1-Students .3.1
• CS101-Students .3.1.101
• CS105-Students .3.1.105
• Label objects with appropriate abilities
• Policy access is given if the objects label is
  a prefix of the subjects label CS101-Students
  have access to objects labelled .3.1.101 or .3.1
  or .3 but not to objects labelled .3.1.105

39
Null Values

• Consider the dual of the previous policy access
  is granted if the subjects ability is a prefix
  of the ability of the object.
• A subject without an ability has access to every
  object.
• Frequent problem when an access control
  parameter is missing the policy is not evaluated
  and access is granted.
• NULL DACL problem in Windows nobody has access
  to a file with an empty ACL but everyone has
  access to a file with no ACL.

40
Towards Lattices

• In our example, how should we label objects that
  may be accessed both by CS101-Students and
  CS105-Students?
• Answer ??
• How should we label a subject that may access
  resources earmarked for CS101-Students and
  resources earmarked forCS105-Students?
• Answer ??
• To answer both questions, we need more structure
  than just partial orderings.

41
Towards LatticesThe slide on lattices to remember

• Assume that a subject may observe an object only
  if the subjects label is higher than the
  objects label. We can ask two questions
• Given two objects with different labels, what is
  the minimal label a subject must have to be
  allowed to observe both objects?
• Given two subjects with different labels, what is
  the maximal label an object can have so that it
  still can be observed by both subjects?
• A lattice is a mathematical structure where both
  questions have unique best answers.

42
Lattice (L,?)The slide on lattices you must not
memorize

• A lattice (L,?) is a set L with a partial
  ordering ? so that for every two elements a,b ? L
  there exists
• a least upper bound u ? L a ? u, b ? u, and
  for all v ? L (a ? v ? b ? v) ? u ? v
• a greatest lower bound l ? L l ? a, l ? b, and
  for all k ? L (k ? a ? k ? b) ? k ? l .
• Lattices come naturally whenever one deals with
  hierarchical security attributes.

43
System Low and System High

• A label that is dominated by all other labels is
  called System Low.
• A label that dominates all other labels is called
  System High.
• System Low and System High need not exist if
  they exist, they are unique.
• When L is a finite set, the elements System Low
  and System High exist.

44
Lattices Example 1

• The natural numbers with the ordering relation
  divides by form a lattice
• The l.u.b. of a,b is their least common multiple.
• The g.l.b. of a,b is their greatest common
  divisor.
• There exists an element System Low the number 1.
• There is no element System High.

45
Lattices Example 2

• The integers with the ordering ? form a lattice
• The l.u.b. of a,b is the maximum of a and b.
• The g.l.b. of a,b is the minimum of a and b.
• Elements System Low and System High do not exist.
  
• (The integers with the ordering ? are a total
  ordering).

46
Lattices Example 3

• (P(a,b,c), ?), i.e. the power set of a,b,c,
  with the subset relation as partial ordering
• least upper bound union of two sets
• greatest lower bound intersection of two sets

Lines indicate the subset relation
47
Multi-level Security

• A partial ordering of security labels is used in
  multi-level (military) security (MLS).
• Mandatory security policies
• Subjects and objects are assigned security
  labels.
• No read up a subject may observe an object
  only if the subjects label dominates the
  objects label.
• No write-down a subject may alter an object
  only if the subjects label is dominated by the
  objects label.
• Trusted as in Trusted Unix or Trusted Solaris
  usually indicates MLS support.

48
Multi-level Security

• Security policy for protecting classified
  information
• Documents are assigned security levels.
• The users clearance dictates which documents the
  user may read.
• Mandatory access control policies (MAC) and
  multi-level security policies of the Orange Book
  use security levels and adapt these policies to
  IT systems.
• In their most elementary version, these policies
  refer to a linearly ordered hierarchy of four
  security levels, unclassified, confidential,
  secret, top secret.

49
Basic Security Levels
50
Compartments

• With the basic security levels, we cannot
  restrict access to documents relating to a secret
  project X just to people working on X anyone at
  level secret would have access.
• To state need-to-know policies that control
  access to the resources of specific projects, the
  following lattice of security levels was
  introduced
• H is a set of classifications with a linear
  ordering ?H.
• C is a set of categories, e.g. project names,
  company divisions, academic departments, etc. A
  compartment is a set of categories.
• A security label (security level) is a pair
  (h,c), where h ? H is a security level and c ? C
  is a compartment.
• The partial ordering ? of security labels is
  defined by (h1,c1) ? (h2,c2) if h1 ?H h2 and
  c1 ? c2.

51
Example Compartments
52
Summary

• Security terminology is ambiguous.
• Access control has to remain manageable.
• More sophisticated policies draw you into
  mathematics.
• Today we have covered classical access control
  we return to current trends later.

53
Further Reading

• Denning, D.E. Cryptography and Security,
  Addison-Wesley, 1982
• Lampson, B., Abadi, M., Burrows, M., Wobber, E.
  Authentication in Distributed Systems Theory and
  Practice, ACM Transactions on Computer Systems,
  vol. 10, 1992, pages 265-310
• Sandhu, R.S. and Coyne, E.J. and Feinstein, H.L.
  Youman, C.E. Role-Based Access Control Models,
  IEEE Computer, vol. 29, February 1996 , pages
  38-47
• Sandhu, R.S. Lattice-Based Access Control
  Models, IEEE Computer, vol. 26, November 1993,
  pages 9-19