DAC, MAC, RBAC, and ABAC

Preface

This lecture is over various schemas for how permissions are determined in the first place.
There are four types of access control that we will discuss

DAC is a type of access control in which the owner of a resource decides which subjects can access the resource and what permissions they have.
In this context, “owner' generally refers to the creator of the resource, but can also apply to any entity granted ownership
- For example, a user create a text file called file1. That user now has authority through DAC to determine which users can access file1 and how(read write etc.)
- that user can modify or revoke the privileges at any time
Implemented using an ACL
Each object a user creates will have its own ACL
- Windows and UNIX systems are common examples of DAC - owner of the file has control of the permissions

Simple to implement - all you need is an owner and an ACL
Cost effective - there is minimal overhead
Highly Flexible - Resources can be shared or restricted easily on a per-object basis

DAC has no inherent centralized access management - ownership is dispersed among many ACLs
DAC relies on trust - you are dependent on the resource owners to set their permission correctly
DAC is incompatible with highly-sensitive data - These include military, medical, or financial records

A type of high-security access control often used in government and military environments
In MAC, access control is governed by a system mechanism, and individual users cannot change access or permissions within that system
For example:
- A hospital employee create a medical record , m1, pertaining to a new patient
- Although the employee created m1, they do not possess “ownership” in the DAC-sense.
- The employee cannot set access to m1, delete m1, or overwrite m1.
MAC is often implemented using clearnace and sensitivity labels.
Labels often organize resources into a hierarchy acccording to their senssitivity (eg. top secret, classified, etc.)
Users can only access a resource for which they have the appropriate level of clearance.
Resources may also be organized into compartments (domain for which the resource is relevant). This governs user acess to resources on a need to know basis

HIgh level of secrutiy - Chance for info leaks or escalation of privileges is much smaller than in DAC, as permissions are tightly maintained
MAC makes it easier to conceptualize which resources a user should be accessing and how.
MAC enables centralized access management; administrators interacting with the system mechanism control access rights.

MAC is more costly than DAC - it requires overhead to implement the system mechanism that mandates access control
MAC requires constant maintenance - permissions must be granted and revoked as-needed by the central authority
Reduces productivity and efficiency - users cannot configure permissions for their own data, so they must outsources this task to the central authority and wait for it to be completed
MAC may introduce the potential for a single point of failure

Grants access rights according to a subject’s role
Subjects do not have any direct permissions. Instead, permissions are tied to roles, and subjects’ permissions are determined by their role.
For example, based on a website:
- Subject 1 is given the guest role. They may read forums on the website, but cannot comment or post.
- Subject 2 is given the registered user role. They can read forums, comment, and make posts
- Subject 3 is given the moderator role. They have privileges of registered users and can also ban other other users and delete their posts

RBAC is based upon three core principles:
1. Role Assignment: A subject can exercise a permission only if the subject has selected or been assigned a role.
2. Role authorization: A subject’s active role must be authorized for the subject.
3. Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject’s active role.

Easy to maintain - once roles are defined, permissions become routine.
Scalable - new subjects need only be given their appropriate roles, and new objects need only specify permissions according to roles
Offer greater structure than DAC (roles are more centralized) but less restriction than MAC (the system is not beholden to a rigid hierarchy).

Defining roles can be challenging and complex - an entire discipline (role engineering) has spawned from RBAC enforcement
Large organizations may experience “role explosion” in which the number of roles in an organization becomes unmanageable.

Type of access control that determines permissions based on the characteristics (i.e. attributes) of the subjects and objects, rather than their identities.
Attributes are defined by measurable values, and rules are set depending on those values.
- For example:
  - A subject S may only edit company documents during works hours
  - Subject S may only view a document if they are at least 18 years of age
  - Subject S ma only access a resource from a company owned device
  - Subject S may access object O only if object O was created on or after a specific date.
- Attributes in ABAC may include:
  - Subject, such as age or department
  - Object, such as file type
  - Action, such as the amount of requested for a transfer of funds
  - Context, such as the time or location of an attempted action

Highly flexible and granular - permissions can be configured in near-infinite combinations according to near-infinite attributes
Dynamic - permissions can be granted or revoked in real-time rather than according to a static standard
Can easily absorb elements of other access control schemas, or be incorporated alongside them.

Like RBAC, it is highly complex - attributes must be identified, quantified, and assigned meaning in relation to rules.
The large number of potential attributes means individual rules can be equally complex and must account for many different scenarios
ABAC permissions are more difficult to conceptualized and/or audit, as they are less intuitive than the other schemas

Although we will not discuss them in detail, other concepts related to access control include:
- Risk Based Access Control 0 Similar to Risk Based Authentication (RBA) - verifies access to resources based on a dynamic assessment of risk
- Originator Controlled Access Control (ORGCON) - Similar to DAC, but control of permissions always remains wit the creator of the resource
- Privileged Access Management - not an access control schema itself, but a set of security procedures / mechanisms to control the access of privileged users.