Access Control

Topics

Access Control mechanisms - Access Operations, Access Control Structures (ACL, ACM, Capability), DAC

Access control consists of two steps, authentication and authorisation.

Principal V/S Subject

Feature	Principal	Subject
Nature	An identity or "account."	A running process or thread.
Persistence	Permanent (exists in a database/registry).	Transient (exists only while running).
Action	Owns the permissions.	Exercises the permissions.
Example	Your Username.	An instance of Chrome or Python.
The principals permitted to access a given object is called access control list

Access Operations

Access Modes

• Observe - look at the contents of the objects
• Alter - change the contents of the objects

Bell-LaPadula Model

The Bell-LaPadula Model has four access rights - execute, read, append, and write

• Enforces MLS
• Combines mandatory and discretionary access controls
• Access permissions are defined both through an access control matrix and through security levels.

Access Control Policies

• Discretionary Access Control - use identity of requester and access rules to control access. Entity may allow access to other entities
• Mandatory Access Control - Compare security labels with security clearances to determine access. Entity has no power.
• Role-based Access Control - Roles of users in system and rules for roles are used to control access
• Attribute based Access Control - access rights are granted to users through the use of policies which combine attributes together.

Discretionary Access Control

• An entity may be granted access rights that permit the entity to enable another entity access a resource.
• Controls access based on the identity of the requester and on access rules stating what requestors are allowed to do.

Files vs. Directories: Functional Differences

In Multics, permissions are mapped from specific actions to the BLP rights: e (execute), r (read), a (append), and w (write).

For Files (Data Segments)

• Read (r): The ability to open the file and view its contents.

• Execute (e,r): Note that in Multics, to execute a file, you also need "read" access so the system can load the instructions into memory.

• Write (w): The ability to modify or overwrite the existing content.

• Append (a): The ability to add data to the end of the file without changing the existing data.

For Directories

Directories are essentially "folders" that contain lists of files. The rights change meaning here:

• Status (r): Equivalent to "Read." It allows you to see the metadata of the files in the directory (like file size or last modified date).

• Status and Modify (w): Equivalent to "Write." This allows you to rename files or change their attributes within that directory.

• Append (a): This allows you to create a new file within that directory.

• Search (e): Equivalent to "Execute." This is a unique concept in OS security; it doesn't mean you "run" the directory, but rather that you have permission to "traverse" it to get to a sub-directory or a file inside, even if you can't list all the files (Status).

Administrative Access Rights

• read - reading from a file / list directory contents
• write - writing to a file / create or rename a file in directory
• execute - executing a program / search the directory

Operations for manipulating a subject’s access rights - grant and revoke

Access Control Structures

let S be a set of subjects, O be a set of objects and A be a set of access operations.

Access Control Matrix

Capabilities

There are two fundamental options for implementing an access control matrix. This capability refers to the subject’s row in the ACM.

Alice’s capability: edit.exe: execute; fun.com: execute, read; Bill’s capability: bill.doc: read, write; edit.exe: execute; fun.com: execute, read, write

Access Control Lists

An access control list stores the access rights to an object itself. An ACL therefore corresponds to a column of the access control matrix. The entries in an ACL are called access control entries (ACE).

ACL for bill.doc:
ACL for edit.exe:
ACL for fun.com:
Bill: read, write;
Alice: execute; Bill: execute;
Alice: execute, read; Bill: execute, read, write

Groups have been made to make this permission management efficient.

Ownership

We must discuss who is in charge of setting security policies.

• We can define owner for each resource and let the owner decree who is allowed to have access. Policies defined by owner are called discretionary.
• A system-wide policy decrees who is allowed to have access. Policies imposed by the system are called mandatory.

Access control based on user identities was called discretionary (identity-based access control). Access control based on policies that refer to security labels for classified documents is called mandatory.

Intermediate Controls

We introduce intermediate layers between users and objects to represent policies in a more manageable fashion.

Groups and Negative Permissions

Negative permissions are used to deny some access to users in a group

Privileges

Role-Based Access Control

• Users are assigned to roles, access rights are assigned to roles
• Roles typically job functions and positions within organisation.
• User may be assigned multiple roles - static or dynamic

Separation of Duties

There exist tasks where certain steps must be executed by distinct users - Static - The roles that maybe assigned to a user are fixed and have to take into account separation-of-duties. - Dynamic - The roles that may be assigned to a user depends on the current task.

Hierarchical RBAC

1. Flat RBAC (The Foundation)

This is the most basic form. Instead of assigning permissions directly to Alice, the administrator creates a "Student" role.

• Mechanism: User → Role → Permission.

• The Review: A user-role review is a simple audit. You ask the system, "What roles does Alice have?" If the answer is both "Student" and "Teaching Assistant," you can verify if that matches her actual job description.

2. Hierarchical RBAC (Inheritance)

In large organizations, roles often overlap. A Professor needs all the permissions of a TA, plus more.

• Mechanism: Senior roles "inherit" the permissions of junior roles.

• Example: If the Teacher role is senior to TA, then any permission granted to the TA (like "Post Grades") is automatically granted to the Teacher. You don't have to assign it twice.

---

3. Constrained RBAC (Business Logic)

This level introduces Separation of Duties (SoD). It prevents conflicts of interest by placing restrictions on role memberships or activations.

• Static SoD: Alice cannot even be assigned both the "Student" and "TA" roles for the same course.

• Dynamic SoD: Alice can hold both roles, but she cannot activate both at the same time. While she is logged in as a "Student" to submit an assignment, she cannot use her "TA" powers to grade it.

4. Symmetric RBAC (Full Auditing)

While Flat RBAC focuses on what a user can do, Symmetric RBAC focuses on what a permission is used for.

• The Review: A permission-role review is an "inverse search." You ask, "Which roles have the power to 'Delete Course'?"

• The Challenge: In massive systems, permissions might be scattered across hundreds of servers. Finding every role that touches a specific sensitive permission is technically difficult but necessary for high-level security compliance.

Need-to-know Principle

• no subject should be able to read objects unless reading them is necessary for that subject to perform its functions
• minimises data breach risks by limiting access to the bare minimum

Security Models

Multi-Level Security (MLS)

Lattice of Security Levels

• A subject may observe an object only if the subject’s security level is higher than that of object
• Given two objects at different security levels, what is the minimal security level a subject must have to be allowed to read both objects? • Given two subjects at different security levels, what is the maximal security level an object can have so that it still can be read by both subjects?

Properties with respect to MAC

• Simple Security Property (ss-property) - “No read up” rule.
• Star Property (-property) - “No write down” rule.
• Discretionary Property (ds-property) - Access to an object is governed by Access Control Matrix or specific permissions assigned by the owner, though the first two properties are mandatory.

Property	Informal Name	Direction	Focus
ss-property	No Read Up	$O \le S$	Confidentiality
*-property	No Write Down	$S \le O$	Information Leakage
ds-property	Discretionary	User-defined	Specific Permissions

Policy Instantiation

Placeholder principals can be kept while developing a software.

Comparing Security Attributes

The reference monitor compares the access rights granted to the subject with access rights demanded by the policy.

Partial Ordering

• Total Ordering: Imagine a ladder. Every rung is either above or below another. Protection rings (0,1,2,3) are like this. You can always say i<j.

• Partial Ordering (Poset): Imagine a family tree or a web. Some things are "above" others, but some are just "side-by-side" and cannot be compared.

  • The Student Example: A "Year 1 Student" and a "Year 2 Student" are both "Students" (so they both sit below the "All Students" group), but a Year 1 student is not "more" or "less" privileged than a Year 2 student—they simply have different, incomparable access rights.

To be a valid partial ordering, the relation (≤) must follow three strict logical rules:

1. Reflexive: You are at least as privileged as yourself (a≤a).

2. Transitive: If a Teaching Assistant ≤ Teacher, and Teacher ≤ Department Head, then Teaching Assistant ≤ Department Head.

3. Antisymmetric: If a≤b and b≤a, then a and b must be the exact same identity. You can't have two different levels that are "higher" than each other.

BLP Model

• a set of subjects
• a set of objects
• the set of access operations
• a set of security levels

Solutions to *-property

• Temporarily downgrade a high-level subject. This is a reason of introducing the current security level fc.
• Identify a set of subjects permitted to violate the *-property

Strong Star Property

• is an alternative to the *-Property
• subjects may write to objects with only a matching security level
• only write-to same allowed

Basic Security Theorem

A state (b,M,f) is called secure if all three properties are satisfied.

The case against BLP

Intuitively, a system that can be brought into a state where everyone is allowed to read everything is not secure

The case for BLP

If the user requirements call for such a state transition, then it should be allowed in the security model

Limitations of BLP

• Only deals with confidentiality, not integrity
• Lack of Access Control Management (Adding new users, deleting objects, changing individual's clearance level, etc)
• Covert channel

Biba Model

• Integrity Policy
• labels subjects and objects with elements integrity levels

• prohibit the corruption of' ‘clean’ high-level entities by ‘dirty’ low-level entities

• Simple integrity property (no write up)

• Integrity *-property (no read-down)

Dynamic Integrity Levels

• policies with dynamically changing access rights
• automatically adjust the integrity level of an entity if it comes into contact with dirty information
• greatest lower bound of fS(s) and fO(o)
• As the integrity levels can be only lowered, there is a danger that all subjects and objects eventually sink to the lowest integrity.

Subject Low Watermark Property

• The reading rule is relaxed
• Subject’s integrity level decreases on reading lower data
• min(sub,obj)
• Ensures that there is no information from low integrity data to high integrity data

Object Low Watermark Property

• The writing rule is relaxed
• The system lower’s object’s integrity label.

Invocation Policy

• extended to include an access operation invoke
• A subject can invoke another subject, to access an object
• Invoke property - fS(subj2) ≤ fS(subj1)
• Ring property - Subject s can read object at all integrity levels. It can only modify objects fO(o) ≤ fS(s)

LOMAC: Low watermark MAC

• System files are high, network at low
• even if the traffic contains an attack that forks a root shell, this shell could not write to the password file due to low integrity
• Windows Vista - Default → NoWriteUp

Multi-lateral Security

• For auditing firms, that audit competing firms
• Conflict of Interest Class - Grouping of company datasets that are in direct competition with one another.

• Simple Security (The Reading Rule): A subject S can only access an object O if:

  • O is in the same Company Dataset as an object S has already accessed.

  • OR, O belongs to a different COI class than any objects S has already accessed.

  • Effect: Once you read "Citibank" data, the "Bank of America" dataset is "walled off" from you forever. However, you could still read data from "Shell Oil" because it is in a different COI class.

• The Writing Rule (Integrity): To prevent indirect information leakage, a subject can only write to an object O if:

  • The subject can read O based on the rule above.

  • AND, the subject has not read any objects in a different company dataset (even in different COI class).

  • Effect: This ensures you don't accidentally leak "Shell Oil" secrets into a "Union '76" document.

Sanitised Document

• Sensitive information is purged

Clarke-Wilson Model

• commerical environments, data integrity model
• Well-formed transactions - data items must be modified only by a specific set of programs; users have access to programs rather than to data items
• Labelling subjects and objects with programs instead of security levels.
• Subjects have to identified and authenticated.
• CDI - Constrained Data Items
• Unconstrained Data Items
• Transformation Procedures
• Integrity Verification Procedures
• Security properties are defined through five certification rules
• Four enforcement rules describe the security mechanisms