Skip to main content
Department of Information Technology

Access Control

After identification and authentication, what can the user do?

  • access control mechanisms
    how do we control access (implementation)
  • access control policies (security policies)
    what should be allowed or not (specification); the security we expect the system to enforce

Access Control Mechanisms

Different at different levels

  • low level: simple, generic (e.g. memory protection)
  • high level: complex, specific (e.g. database protection)

Important concepts

  • active part: subject (users, processes, methods, domains...)
  • passive part: object (memory, device, file, process, method...)
  • action: access operation (read, write, execute...)

Subject makes an access request (reference), which is checked by reference monitor.
Subjects (typically) subset of objects (i.e. subjects are also objects).

(Fig 4.1.)

Book definitions:

  • Subject: "active entity within an IT system".
  • Principal: "an entity which can be granted access or make statements affecting access control definitions". A subject is bound to a principal ("represents" the principal).
1.1. Authentication vs Authorization
  • Authentication: who made the request?
  • Authorization: is the subject authorized/trusted to perform the operation?
1.2. Access operations

1.2.1. Access modes:

  • basic: observe, alter
  • useful abstraction in access control policies
  • too abstract for mechanisms

1.2.2. Access rights/permissions:

Examples:

  • Memory: e.g. read, write, execute, copy-on-write.
  • Files:
    • Unix: read, write, execute
    • TOPS-20: r, w, x, append, list
    • Windows NTFS: r, w, x, delete, change perm, change owner
  • Directories:
    • Unix: list contents, create/rename/delete (change) contents, access contents
    • TOPS-20: access contents, create files, ownership (delete, rename...)
    • Windows NTFS: list contents, add contents, change cont ...

Note:

  • same permission bits often used with different meaning for files/directories (Unix: list cont=read, change cont=write, access cont=execute)
  • different approaches Windows vs Unix/T20 wrt. delete/change perm/change owner
1.3. Who sets permissions?
  • Discretionary Access Control (DAC):
    • "owner" can set permissions as desired (discretion: individual choice or judgment)
    • users make mistakes or even consciously "leak" permissions
  • Mandatory Access Control (MAC):
    • system-wide policy regulates access
  • Combination: MAC has precedence over DAC

Access control structures

How do we specify the rights/permissions? Abstraction: Access Control Matrix

  • subjects S, objects O, access operations A
  • matrix M indexed by subject s in S and object o in O: contents = access rights (subset of A)

Example:

exercise.txt solution.txt grades/
victor r,w r,w r,w,x
magnusj r r r,w,x
foba1234 r - x
2.1. Access Matrix implementation

Consider 5000 users, 1e6 files: large, sparse matrix.

Implementations (skipping empty cells):

  • row-wise: capability lists (CL)
  • column-wise: access control lists (ACL)

2.1.1. Capabilities

Intuition: each subject has a booklet of tickets to show to the reference monitor: "look here, I have these rights to that object".
I.e. each subject s has {A(s,o) for each o in O}

Capabilities must be unforgeable (just like tickets) and protected.

Implementation:

  • low level: protected by operating system kernel, e.g. page table, MMU, open file descriptor
  • high level: cf. certificates: so far "this is my identity", but also/instead "these are my rights"

Feature:

  • a capability (or parts of it) could be passed to another subject (delegation)

Drawbacks:

  • Hard to see who has what access to a particular object.
  • Hard to revoke capabilities (esp. with delegation). Possible solution (in distributed setting):
    • revocation lists: used for certificates; issued by CA, e.g. on request from cert owner. Need to be checked when verifying the capability.

2.1.2. ACL (Access Control Lists)

Intuition: each object has an admission list, checked by the reference monitor: "hmm, can I allow this subject to access this object?"
I.e. each object o has {A(s,o) for each s in S}.

Good for owned objects (e.g. files):

  • owner has full control over who has what access to his/her objects

Difficulties:

  • hard to see which rights a particular subject s has, e.g. for revoking all rights of s
  • expensive to check on each access: file systems check when opening a file, not at each read/write (TOCTTOU problem: Time Of Check To Time Of Use)
2.2. Groups

Useful generalisation: (user) groups.

  • Unix: rights specified for owner, group, others (recent ACLs: additional users/groups)
  • Check first user, then group, then others (ex: owner no access, group has access, owner in group => owner has no access)
  • Standard: File has one group, user can be a member of several
    • variants: (SysV) user has one active group (has to switch), or (BSD) user has all groups "active"

Explicit negative permissions useful in group-based ACLs, e.g. "group G may NOT have write access" (e.g. NTFS)
Problem:

  • if the user is in two groups, one which has write access and one which has NOT.
  • usual solution: order deny/allow
2.3. Privileges

Privileges typically override or replace ACL checking for operating system operations such as network configuration, backup, and other administration.

Can often be seen as capabilities, preferrably possible to enable/disable privileges.

Cf. the "root" super-user in Unix (single privilege, implemented with more fine-grained ones in Linux), or TOPS-20 "capabilities" (privileges).

Updated  2006-09-05 08:04:58 by Björn Victor.