Underlying Protection Mechanisms for Access Control

Before studying access control models, it helps to understand the hardware and operating system features that make them possible.

The operating system enforces access control by managing both software and hardware resources. It allocates CPU time through the scheduler, ensuring that no process monopolizes the processor and that all processes get a fair chance to run. It configures the hardware timer, which generates periodic interrupts so the operating system can regain control of the CPU—this enables preemptive multitasking.

It also manages the Memory Management Unit (MMU), setting up each process’s page tables to define what regions of memory it can read, write, or execute. The MMU translates a process’s virtual addresses into physical memory and prevents one process from accessing another’s data.

Processors support at least two privilege levels:

• Kernel mode (privileged): used by the operating system to execute sensitive instructions, modify memory mappings, and handle interrupts.

• User mode (unprivileged): used by applications, which must request system services through controlled system calls.

These mechanisms ensure that untrusted code cannot modify the kernel or access protected resources directly. They provide the foundation on which all access control models --discretionary, mandatory, and role-based -- are built.

Access control

Access control defines what authenticated users and processes are allowed to do. Its purpose is to preserve confidentiality, integrity, and availability by enforcing consistent rules for access to information and system resources.

Different models evolved as computing environments became larger and more complex. Each model solves specific problems but introduces new trade-offs.

The main models are Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and the Chinese Wall model.

The Access Control Matrix

Access control can be represented as a matrix showing which subjects (users or processes) have which rights over which objects (files, directories, or devices). Although the matrix is a conceptual model, it underlies nearly all practical access control mechanisms.

Two common implementations are:

• Access Control Lists (ACLs): permissions stored with each object.

• Capabilities: permissions stored with each subject.

This model inspired later systems such as UNIX file permissions and modern ACL-based operating systems.

Discretionary Access Control (DAC)

Discretionary Access Control gives control to the owner of an object. The owner decides who else can access it and what operations they may perform.

This model encourages sharing but relies heavily on user behavior and trust.

The UNIX / POSIX Model

UNIX and POSIX systems (e.g., Linux, macOS, Android, and the various flavors of BSD) implement DAC through file ownership, groups, and permission bits. Each file has an owner, an owning group, and three sets of permissions for the owner, group, and others.

Permissions are represented by three bits for each category: read (r), write (w), and execute (x).
For example, rwxr-xr-- means the owner can read, write, and execute; the group can read and execute; others can read only.

The chmod command changes permissions, chown changes ownership, and chgrp changes the owning group.

A user’s umask defines which permissions are removed from newly created files, preventing overly permissive defaults.

Each process runs with a real user ID (ruid) and an effective user ID (euid), which determine ownership and access rights.

UNIX uses the setuid and setgid bits to let certain programs temporarily assume the privileges of the file’s owner or group. This is useful for programs that must perform privileged actions, such as changing a password, but it is also risky. Any vulnerability in a setuid program can grant attackers full system privileges.

Modern Linux systems support extended attributes (ACLs), which provide more flexible per-user or per-group permissions than the simple owner-group-other model.

Principle of Least Privilege and Privilege Separation

DAC systems rely on careful assignment of permissions. The principle of least privilege states that each user or process should have only the permissions necessary to complete its task.

Privilege separation divides a program into privileged and unprivileged parts so that most operations run with minimal authority.
For example, a web server may start as root only to bind to a port, then drop privileges for normal operation.

Weaknesses of DAC

DAC is easy to administer and flexible but insecure for high-assurance environments. Users can share data freely, and malicious software can exploit user privileges to leak or destroy data.

DAC cannot enforce consistent organizational or system-wide policies.

Mandatory Access Control (MAC)

Mandatory Access Control enforces a system-wide security policy that users cannot override.

Both subjects and objects have security labels, and access decisions depend on comparing these labels. Users are assigned clearance levels, and resources are assigned classification levels.

This model was originally developed for military and intelligence systems that required strict confidentiality.

Bell–LaPadula Model (Confidentiality)

The Bell–LaPadula (BLP) model is the foundation of what is known as multilevel security (MLS).

In an MLS system, both users (subjects) and data (objects) are labeled with levels such as Unclassified, Confidential, Secret, and Top Secret.

Access decisions depend on these relative levels, enforcing “no read up” and “no write down” to prevent data from flowing from higher to lower classifications.

The Bell–LaPadula model ensures confidentiality through two main rules:

1. Simple Security Property: no read up. A subject cannot read information above its clearance level.

2. Star (∗) Property: no write down. A subject cannot write information to a lower classification level.

A third rule, the Discretionary Security Property, allows normal access control lists within the bounds of the mandatory policy.

This ensures information flows only upward in classification, preserving confidentiality.

Weaknesses: The model protects secrecy but not integrity. It also makes collaboration difficult since data cannot be shared downward without special downgrading mechanisms.

Multilateral Security and the Lattice Model

Organizations often require boundaries between peers at the same classification level. Multilateral security extends Bell–LaPadula by dividing each level into compartments, which represent separate projects, missions, or domains of information. A user must have both the appropriate clearance and authorization for the relevant compartment.

For example:

• A file labeled {Top Secret, Nuclear} can be accessed only by users cleared for Top Secret and authorized for the Nuclear compartment.

• Another file labeled {Top Secret, Signals} requires authorization for the Signals compartment.

• A user cleared for {Top Secret, Nuclear} cannot read {Top Secret, Signals} data even though both are Top Secret.

This approach enforces the need-to-know principle, ensuring that access within the same classification level is limited to those who require it for their duties.

The lattice model formally defines the relationship between classifications and compartments.

Label A dominates label B if its classification level is greater than or equal to B’s and its compartments include those of B. Information can only flow upward in this lattice.

Weaknesses: This approach enforces strong confidentiality but is complex to administer. Managing compartments and clearances becomes difficult at scale, and cross-compartment collaboration is often restricted.

Biba Model (Integrity)

The Biba model complements Bell–LaPadula by protecting data integrity instead of secrecy. It reverses the BLP rules:

• Simple Integrity Property: no read down. A high-integrity process cannot read low-integrity data.

• Star (∗) Integrity Property: no write up. A low-integrity process cannot modify high-integrity data.

This ensures that untrusted input cannot corrupt trusted data or processes. Biba models appear in applications where data accuracy matters more than confidentiality, such as medical or financial systems.

Microsoft Mandatory Integrity Control (MIC) implements a simplified version of Biba in Windows.

It labels processes and objects as Low, Medium, High, or System integrity and enforces a no write up rule. MIC prevents low-integrity programs like browsers from altering system files. Later versions of Windows integrated MIC into the AppContainer framework, combining it with capability-based restrictions.

Weaknesses: Biba models may block legitimate data flow and are rarely practical for general-purpose systems. Like Bell–LaPadula, they are most effective in specialized environments.

Type Enforcement (SELinux)

Type Enforcement provides a practical way to apply MAC in general-purpose systems.

Processes run in domains, and files and resources are labeled with types.

A policy defines which domains may access which types and how.
For example, a web server in domain httpd_t may read only files labeled httpd_sys_content_t.
This prevents compromised software from affecting other parts of the system.

Type Enforcement forms the basis of SELinux, SEAndroid, and similar systems. It allows fine-grained control and isolation but can be difficult to configure and audit.

Type Enforcement provides the strongest form of containment in modern UNIX systems and remains the most practical way to apply MAC in general-purpose environments.

Role-Based Access Control (RBAC)

RBAC shifts control from individual users to organizational roles. Permissions are assigned to roles, and users acquire permissions by being assigned to roles.

A user may activate one or more roles during a session, depending on the task. A user’s effective permissions are determined by the roles that are active in that session; inactive roles contribute no privileges.

Roles correspond to job functions such as Doctor, Nurse, Manager, or Auditor.
This model scales well in large organizations where many users perform similar tasks.

Role hierarchies allow senior roles to inherit permissions from junior ones.
Constraints enforce separation of duties, ensuring that no single person can perform conflicting actions such as initiating and approving a transaction.

RBAC fits naturally with business structures and enables consistent policy enforcement across systems. It is used in databases, enterprise directories, and cloud identity management.

Weaknesses: RBAC works well for static organizations but cannot express context such as time, location, or risk level. Large deployments may suffer from role explosion when too many narrowly defined roles are created.

Attribute-Based Access Control (ABAC)

ABAC extends RBAC by using attributes instead of fixed roles to make access decisions. Attributes describe properties of users, objects, and the environment, allowing flexible and context-sensitive control.

An example policy might be:

Allow access if the user's department equals the object's department and the request occurs during business hours.

Example Attributes

• User attributes: department, clearance, role, device security level

• Object attributes: classification, owner, project

• Environmental attributes: time, location, authentication strength

ABAC policies are evaluated by a policy decision point (PDP) and enforced by a policy enforcement point (PEP), often distributed across multiple systems in large-scale environments.

They allow dynamic conditions but can be complex to test and manage.
Cloud platforms such as AWS IAM and Google Cloud use ABAC-style rules to refine role-based access.

Weaknesses: ABAC offers flexibility but poor transparency.
Policies may interact in unexpected ways, and administrators may find it difficult to reason about all possible conditions.

The Chinese Wall Model

The Chinese Wall model handles conflicts of interest in consulting, law, and finance.

Access depends on a user’s history, not just attributes or roles.
Once a user accesses data for one client, the system prevents access to competing clients’ data within the same conflict class.

For example, a consulting firm may define:

• Beverage class: {Coca-Cola, PepsiCo, Keurig Dr Pepper}

• Airline class: {United, Delta, JetBlue, American Airlines, Alaska Airlines}

An analyst who views Coca-Cola’s data can no longer view PepsiCo’s or Keurig Dr Pepper’s confidential data, but can still access airline clients.
This dynamic restriction enforces need-to-know and prevents cross-client information flow.

The model is a dynamic form of separation of duties, where restrictions depend on a user’s previous actions rather than static role definitions.

Sanitizing Data

In practice, sanitized or anonymized information may be shared across conflict classes without violating the Chinese Wall policy.

Aggregate statistics or generalized insights can be used safely once identifying details are removed, allowing useful analysis while maintaining confidentiality.

Weaknesses: It requires accurate tracking of user activity and careful definition of conflict classes. Overly broad classes can block legitimate work; overly narrow ones may miss conflicts.

Comparative Overview

Access control models evolved to address different needs and trade-offs.

Key Takeaways

• DAC allows user-managed sharing but offers weak containment.

• MAC enforces strong, system-defined confidentiality and integrity rules but is hard to manage.

• RBAC organizes permissions by job function for scalable administration.

• ABAC adds flexibility through attribute-based, context-aware decisions.

• Chinese Wall prevents conflicts of interest by making access depend on prior actions.

• The principle of least privilege and privilege separation apply across all models to minimize risk.

• Real systems combine multiple models to balance usability, assurance, and administrative effort.

Next: Terms you should know