pk.org: Computer Security/Lecture Notes

Access Control - Part 4

Role-Based, Attribute-Based, and Chinese Wall Models

Paul Krzyzanowski – October 2025

Part 1: Protection and Hardware Support for Access Control
Part 2: Discretionary Access Control
Part 3: Mandatory Access Control
Part 4: RBAC, ABAC, and Chinese Wall

Mandatory Access Control (MAC) vs. mandatory access control

The next set of access controls are also mandatory, in the sense that users cannot override the policy. In the broad sense, any access controls where users cannot change the decisions that are enforced by the system are mandatory access control mechanisms.

However (unfortunately), in computer security theory well-referenced literature such as the Trusted Computer System Evaluation Criteria and Common Criteria, MAC refers specifically to systems based on security labels that encode information sensitivity and subject clearance. It’s tied to multilevel security models like Bell–LaPadula (for confidentiality) and Biba (for integrity).

In this restricted sense:

The models we'll cover here don't fit that definition because:

It's a subtle difference we can argue that it's not a particularlly useful distinction but when security engineers say MAC, they usually mean label-based control over information flow: systems that enforce formal secrecy or integrity levels.

Role-Based Access Control (RBAC)

As organizations grew more complex, neither discretionary nor mandatory access control alone could handle the scale of modern enterprise environments. Discretionary controls were too decentralized, relying on individual users to manage permissions; mandatory controls were too rigid and difficult to adapt to changing organizational roles. The solution that emerged in the early 1990s was Role-Based Access Control (RBAC), which shifted focus from users and objects to roles.

The basic idea in RBAC is that users are not granted permissions directly. Instead, they are assigned to roles, and those roles are assigned permissions. A user’s effective privileges are the union of all permissions associated with the roles that are active in a given session. A user may have several roles but may choose or be required to activate only one or a subset of them at a time, depending on the task being performed.

Roles are designed to represent fine-grained job functions rather than unrestricted access to entire databases or systems. A role defines specific operations such as edit customer contact information, approve purchase order, or submit expense report. This mapping of real-world responsibilities to controlled actions supports least privilege and allows flexible combinations of authority without excessive complexity.

Origins and Development

The RBAC concept emerged informally in commercial systems in the 1980s but was first formally defined by David Ferraiolo and Richard Kuhn at NIST in 1992. Later, Ravi Sandhu and colleagues unified the various formulations into the NIST RBAC model, which became the de facto standard for enterprise security architecture.

RBAC’s primary goal was administrative scalability. Instead of managing thousands of user-to-permission mappings, administrators manage a smaller and more stable set of role-to-permission relationships. When an employee changes departments, their role assignment changes, not the underlying permissions. This approach fits naturally with organizational hierarchies.

RBAC Concepts

An RBAC system defines several basic entities:

These entities interact to produce a session-specific authorization state that determines what each user can do at runtime.

When a user logs in, the system activates the roles associated with that user in a session. The permissions attached to those roles define what actions the user can perform.

Role Hierarchies

Roles can be arranged in hierarchies that mirror an organization’s structure.

A senior role inherits the permissions of a junior one. For example, a Manager role may include all the permissions of an Employee role plus additional privileges.

This hierarchy simplifies management and enforces the principle of least privilege by letting administrators combine only the permissions needed for each job level rather than creating redundant roles.

Constraints and Separation of Duties

RBAC supports constraints, which are rules limiting how roles and users can be combined. A common example is separation of duties (SoD). SoD prevents a single individual from holding conflicting responsibilities that could enable fraud or accidental misuse. For instance, a user who can initiate a financial transaction should not also be allowed to approve it.

Constraints can be static (preventing assignment of conflicting roles) or dynamic (restricting role activation within a session). These constraints give administrators a powerful way to enforce business policies.

Example: A Hospital System

Consider a hospital information system with roles such as Doctor, Nurse, Billing Clerk, and Administrator. Each role has specific permissions:

Role Example Permissions
Doctor Read and update patient charts, write prescriptions
Nurse Read patient charts, update vital signs
Billing Clerk Access billing data, submit invoices
Administrator Manage user accounts, assign roles

A user assigned both the Doctor and Researcher roles can access clinical data for patients and anonymized datasets for research but cannot access billing information unless also assigned to that role. This separation of access supports both patient privacy and operational efficiency.

RBAC in Practice

Modern operating systems, databases, and cloud services all rely on RBAC principles (to varying degrees).

In large organizations, RBAC becomes the foundation for policy-based management, enabling centralized auditing, automated provisioning, and regulatory compliance.

Relation to MAC and DAC

RBAC is often considered a form of mandatory access control in the broad sense because users cannot arbitrarily grant or revoke permissions. The policy is centrally administered, and only authorized administrators can modify role definitions. It occupies a middle ground between the flexibility of DAC and the rigidity of classical MAC models.

Limitations

RBAC’s strength -- its alignment with organizational structure -- can also be a weakness. Poorly designed role hierarchies lead to role explosion, where hundreds of narrowly defined roles appear. This increases complexity and defeats the model’s intent. Overlapping or inconsistent roles can create excessive privileges, violating the principle of least privilege.

In dynamic or context-sensitive environments, RBAC alone is insufficient. It cannot express policies that depend on time, location, device, or environmental factors. These limitations motivated the development of Attribute-Based Access Control (ABAC), which generalizes RBAC with rule-based decision making.

Role-Based Access Control replaced ad hoc permission management with a structured, scalable model. By defining permissions in terms of organizational roles, it provides administrative efficiency, consistency, and auditability. RBAC remains the dominant approach in enterprises, serving as the backbone for most large-scale identity and access management systems.

Attribute-Based Access Control (ABAC)

Role-Based Access Control works well when job responsibilities are stable, but it cannot easily adapt to context. Many real-world decisions depend on attributes of the user, the resource, or the environment. Attribute-Based Access Control (ABAC) generalizes RBAC by making access decisions based on these attributes rather than fixed roles alone.

In ABAC, policies are written as if–then rules that describe who can access what, and under what conditions. For example:

Attributes can describe:

Access decisions are made by evaluating these rules whenever a user requests access to a resource. This approach provides fine-grained and flexible control but can become complex when many attributes interact or when policies overlap.

The model supports highly flexible and fine-grained control, but can be difficult to administer when many attributes interact or when policies overlap.

Example

A cloud storage system might use a rule such as: 

allow(user, object, action)
if user.department = object.department and
object.confidentiality ≤ user.clearance

This rule lets users access only documents that belong to their department and are at or below their clearance level.

Relation to RBAC

RBAC can be viewed as a simple form of ABAC where the only attribute is the user’s role.
Many systems combine both: RBAC provides a baseline of permissions, while ABAC adds contextual conditions such as time, location, or device security.

Modern cloud platforms, such as AWS IAM and Google Cloud, use ABAC-style conditional access policies based on these ideas.

Limitations

ABAC policies can be powerful but complex. The large number of possible attribute combinations makes policies harder to understand, test, and audit. In practice, organizations often start with RBAC and layer ABAC selectively to handle context-aware conditions.

This extension represents the natural evolution of access control models: from discretionary ownership to centrally defined roles, and finally to dynamic, context-sensitive policies. The next model, known as the Chinese Wall, takes a different approach by enforcing conflict-of-interest restrictions based on a user’s past actions rather than fixed attributes.

The Chinese Wall Model

Access control models such as DAC, MAC, RBAC, and ABAC define permissions in advance using ownership, classification, roles, or attributes. The Chinese Wall Model, proposed by Brewer and Nash in 1989, introduced a different dimension: decisions that depend on a user’s prior activity. It was designed to prevent conflicts of interest in industries such as finance, consulting, and law, where confidentiality requirements change dynamically based on which clients a consultant serves.

The name “Chinese Wall” refers to an information barrier -- a policy that prevents individuals from accessing competing or conflicting information within the same organization.

Motivation

Consider a financial analyst working for an investment firm. The analyst might need to access confidential data from multiple corporate clients. If that analyst views the data of one company, it would be inappropriate to later access or advise on the data of a company's direct competitor. This is not a matter of clearance level but of conflict of interest. The system must therefore prevent such cross-access after the first access occurs.

Traditional access control models cannot handle this because their rules are static. The Chinese Wall model solves this by making authorization history-dependent.

Core Idea

Each user can access data belonging to multiple conflict of interest (CoI) classes, but once the user accesses data in one class, the system prevents access to any other data in the same class that belongs to a competing organization.

Think of a consulting firm whose clients include both beverage companies and airlines.
Two conflict of interest classes might be:

At the start of a project, a consultant can access any client’s confidential data because no conflict yet exists. Suppose an analyst opens a market analysis report for Coca-Cola. The system records that event. From then on, the analyst cannot access confidential material belonging to PepsiCo or Keurig Dr Pepper, since those companies fall within the same conflict class.

However, the analyst can still work with clients in unrelated industries -- for example, access confidential data for United Airlines -- because it belongs to a different conflict class.

In this model:

This captures the real-world "need-to-know" boundary found in consulting, accounting, and legal firms, where confidentiality agreements prevent a single employee from advising competing clients.

Formally:

Relationship to Separation of Duties

The Chinese Wall model is a dynamic form of separation of duties. Static separation of duties prevents users from being assigned conflicting roles (for example, one user cannot be both Purchaser and Approver).

Dynamic separation of duties, as expressed in the Chinese Wall model, prevents users from performing conflicting actions within the same session or history. It ensures that a person who has acted for one client cannot later act for that client’s competitor without explicit clearance.

Implementation Concepts

While the model is conceptually simple, implementing it requires tracking access history and updating permissions dynamically.

Practical implementations usually appear in business applications, case management systems, and workflow engines rather than in operating system kernels.

The same principle applies in law firms or accounting practices, where attorneys or auditors are restricted from working on opposing or competing clients once they have accessed a particular client’s confidential information.

Sanitizing Data

In practice, organizations often need to reuse or analyze information across conflict classes without violating confidentiality rules. The Chinese Wall model allows this if the data is sanitized or anonymized so that no client-identifying or confidential details remain.

For example, a consulting firm might share aggregated industry metrics, performance benchmarks, or anonymized market summaries that reveal trends without exposing specific client information. Sanitization provides a controlled way to preserve analytical value while maintaining the model’s core goal -- preventing conflicts of interest and indirect disclosure.

Strengths and Limitations

Strengths

Limitations

Summary: Chinese Wall

The Chinese Wall model captures an important reality that other models overlook: access decisions sometimes depend on what a user has done in the past, not just who they are or what they are authorized for. It enforces a dynamic, need-to-know policy that prevents information from crossing organizational boundaries in ways that could create conflicts of interest.

Although rarely implemented at the operating system level, its principles are widely applied in corporate compliance systems, law firms, and financial institutions where trust and independence are critical.

Summary: Evolution of Access Control Models

Access control mechanisms evolved over time to solve progressively broader and more complex problems. Each model reflects the environment and priorities of its era: early time-sharing systems emphasized personal control, military systems demanded formal secrecy, enterprises needed administrative scalability, and modern organizations require flexibility and context-awareness.

Model Primary Goal Who Defines Policy Key Strength Key Limitation
Discretionary Access Control (DAC) Resource sharing Individual owners Simple and user-friendly Vulnerable to misuse and Trojan horses
Mandatory Access Control (MAC) Confidentiality and integrity System or administrator Enforces global policy Rigid and hard to manage
Role-Based Access Control (RBAC) Organizational scalability Central administrators Maps naturally to job functions Static and coarse-grained
Attribute-Based Access Control (ABAC) Context awareness Central administrators Highly flexible and dynamic Complex policy management
Chinese Wall Model Conflict-of-interest prevention System based on user history Dynamic ethical control Requires precise tracking and policy definitions

From Discretionary to Mandatory

Early multi-user systems like UNIX relied on DAC to allow users to share files easily. This model worked well in cooperative settings but failed in secure or classified environments where users could inadvertently leak data. Mandatory Access Control addressed that problem by enforcing system-wide policies that users could not override, as formalized by the Bell–LaPadula and Biba models.

From Mandatory to Organizational Control

As computing moved into business and government networks, organizations needed a more flexible model that aligned with job functions rather than security classifications. Role-Based Access Control achieved this by grouping permissions into roles such as Manager, Accountant, or Nurse. RBAC reduced administrative burden and became the foundation for enterprise directory services and identity management.

From Roles to Context

Modern distributed systems and cloud environments require finer control than static roles allow. Attribute-Based Access Control expanded RBAC by adding contextual attributes -- such as department, data sensitivity, time of day, or device security -- to make access decisions dynamically. ABAC policies evaluate these attributes dynamically to decide whether to grant access, enabling location-aware and risk-based authentication systems.

Managing Conflicts and Ethics

The Chinese Wall model introduced another perspective: access decisions that depend on what a user has done in the past. It ensures ethical separation between competing clients and has become central to compliance management in consulting, financial, and legal environments. It shows that security is not only about secrecy or permissions but also about maintaining professional trust and independence.

Common Principles Across Models

Despite their differences, all models embody several shared principles:

Modern Practice

Contemporary systems combine elements of all these models:

The result is not a single universal model but a layered architecture that balances security, usability, and manageability. Understanding how each model evolved -- and what problem it solved -- gives security professionals the foundation to choose and design appropriate access control mechanisms for their own environments.

Next: Study Guide