Lec4 Access Control

What is Access Control?

Definitions

1. Encyclopedia of Cryptography and Security (2011)

protects shared resources against unauthorized accesses based on an access control
policy.
2. RFC 4949 (Internet Security Glossary)
regulates the use of system resources by:
Enforcing a security policy.
Allowing only authorized entities (users, programs, processes, or systems) to access
resources according to the policy.
3. Access control is a core component of computer security, supporting the CIA triad
(Confidentiality, Integrity, and Availability).
1. Preventing unauthorized users from accessing resources.
2. Preventing authorized users from accessing resources in an unauthorized manner.
3. Enabling authorized users to access resources as intended.

Examples: Which Security Objective is Not Met?

1. Confidentiality breached: A journalist reading a politician’s medical record.
2. Integrity breached: A criminal performing fake bank account bookings.
3. Availability breached: A company overloading a competitor’s systems to prevent meeting
a critical deadline.

Access Control Context (functions)

1. Authentication: Verifying the credentials of a user or entity.
2. Authorization: Granting or denying access to a system resource.
3. Auditing: Reviewing and examining records to (ensure policy compliance, detect
breaches, and recommend changes).
Key Elements

Subject: An entity (e.g., user or process) whose access is regulated.

Classes: Owner, Group, World.
Object: A protected resource (e.g., file, memory, program).
Access Rights: The way in which a subject may access an object(e.g., Read, Write,
Execute, Delete).
Access Control Models
1. Discretionary Access Control (DAC)
Controls access based on the subject's identity
2. Mandatory Access Control (MAC)
Controls access based on comparing security labels (sensitivity).
3. Role-Based Access Control (RBAC)
Controls access based on the roles users have in the system and their associated
permissions.
4. Attribute-Based Access Control (ABAC)
Controls access based on attributes of the user, resource, and environmental
conditions.

Discretionary Access Control (DAC)

Overview

A security model where subjects (owners) determine who can access their objects.
Access is based on the identity of users.
Commonly used for managing access to data objects like files, directories, etc.

DAC Structures
1. Access Matrix

Represents access rights in a tabular format.

Structure:
- Rows (Subjects): Represent entities (users, processes) that can access resources.
- Columns (Objects): Represent resources (files, directories).
- Entries: Specify the access rights of a subject to an object (e.g., Read, Write).

2. Access Control List (ACL)

Definition: Associates each object with a list that indicates the access rights for each
subject.
Implementation: Each column of the access matrix is stored with the object
corresponding to that column.

3. Capability List

Definition: Associates each subject with a list of its access rights (capabilities) for various
objects.
Implementation: Each row of the access matrix is stored with the subject corresponding
to that row.

4. Authorization Table

Definition: explicit rows subject-action-object combination.

Implementing DAC in Relational Databases

Object Ownership:
The creator of an object in a database is its owner and has full control over it.
By default, no other user can access the object unless explicitly granted access.
Privileges Management:
GRANT Statement: Used to provide specific access rights to users.
REVOKE Statement: Used to remove access rights that were previously granted.
Rules:

- Only explicitly granted privileges can be revoked.

Implementing DAC in Relational Databases

Levels of Privilege Assignment

1. Account Level:
Privileges are assigned to user accounts, independent of database relations.
Syntax:

GRANT {ALL | privilege-list } TO {user-list} [ WITH GRANT OPTION ];

Examples:
GRANT ALL TO User1;
GRANT CREATE TABLE TO User2, User4;
The privilege list:
CREATE TABLE
CREATE SCHEMA
CREATE VIEW
ALTER
DROP
WITH GRANT OPTION: Allows users to propagate their privileges to others.
2. Relation/Table Level:
Privileges are assigned for specific database objects (tables, views, etc.).
Syntax:

GRANT {ALL | privilege-list } ON {DB objects} TO {user-list} [ WITH

GRANT OPTION ];

Examples:
GRANT SELECT ON employee TO user1;
GRANT UPDATE ON employee(address) TO user2;
The privilege list
SELECT
DELETE
INSERT
UPDATE
REFERENCES

REVOKE Statement

Used to remove privileges from users or roles.

Syntax:

REVOKE {ALL | privilege-list } ON {DB objects } FROM {user-list | role-

list } [CASCADE | RESTRICT];

Options:
CASCADE: (Recursive revoke) Removes privileges dependent on the revoked ones.
RESTRICT: Prevents the operation if dependent privileges exist.
Example:

REVOKE SELECT ON employee FROM user1;

Row-Level Privileges

Restricting access to individual records:

1. Create a view for the desired rows:
CREATE VIEW view_name AS
SELECT column1, column2, ...
FROM table_name
WHERE condition;

2. Grant privileges on the view.

Mandatory Access Control (MAC)

Overview
Developed for hierarchical control of access to resources (e.g., government systems).
Controls the flow of information to ensure security.
Prevents unauthorized access and data transfer.

Bell-LaPadula (BLP) Model

Based on comparing the security clearance of subjects and classification of objects.
level that indicates the sensitivity of the object.
level that indicates how much the subject can be trusted

Key Rules

1. Simple Security Rule (No Read Up):

A subject can read objects only at their level or lower.
Prevents unauthorized reading of sensitive information.
2. Star (*-Property) Rule (No Write Down):
A subject can write objects only at their level or higher.
Prevents sensitive information from being leaked to lower levels.
3. Strong Star (*-Property) Rule:

- Subjects can write only to objects at the **same level**.

- Alternative to the *-Property, motivated by **integrity concerns**.
Hierarchy of Classifications

Top Secret (TS) > Secret (S) > Confidential (C) > Unclassified (U)
Subject clearance and object classification are determined by security administrator.
Users cannot overwrite the security policy

Implementing MAC in Databases

1. Security Classifications:
Assign security levels to subjects (users) and objects (tables, tuples, views).
2. Rules:
Read Down: A subject can read an object only if class(subject) ≥
class(object) .
Write UP: A subject can write to an object only if class(subject) ≤
class(object) .
3. Example Scenarios:

- Original `EMPLOYEE` table shows all tuples (Secret(s) - Confidential

(C) - Unclassified (U)) .
- Filtered views for **Confidential (C)** users show limited data.
- Filtered views for **Unclassified (U)** users show even less data.
Role-Based Access Control (RBAC)
Overview

Traditional DAC systems define access rights for individual users.

RBAC assigns access rights to roles instead of individual users.
Users are assigned roles based on their responsibilities.
Key Characteristics

The relationship between users and roles, and roles and resources, is many-to-many
(M:N).
Dynamic Elements:
The set of users and their assignment of a user to one or more roles change
frequently.
Static Elements:
- The set of roles is relatively stable, with rare additions or deletions.
- The set of resources and access rights associated with roles change infrequently.

Hierarchical Role-Based Access Control (HRBAC)

Roles are structured in a hierarchy.
Higher roles inherit the access rights of lower (subordinate) roles.
Implementing RBAC in Relational Databases
Commands

Role Management:
CREATE ROLE and DROP ROLE to add or remove roles.
Assign Privileges:
Use GRANT and REVOKE to manage:
Privileges for roles.
Users assigned to roles.
Hierarchical role relationships.

Example

CREATE ROLE AdvisorRole;

CREATE ROLE InstructorRole;
GRANT SELECT ON Student TO AdvisorRole;
GRANT SELECT ON Enroll TO InstructorRole;
GRANT InstructorRole TO AdvisorRole;
GRANT AdvisorRole TO User1;
GRANT InstructorRole TO User2;

RBAC Constraints
Purpose: Adapting RBAC to the specifics of administrative and security policies of an
organization.
Types:
1. Mutually Exclusive Roles:
A user can only be assigned to one role in the set.
- Example: A student cannot be both “Undergraduate” and “Postgraduate.”
2. Cardinality Constraints:
Setting a max number with respect to roles.
- Example: Only one user can be assigned the “Dean” role.
3. Prerequisite Roles:
A user can only be assigned to a particular role if it is already assigned to some other
specified role
- Example: A user must have the “Professor” role before being assigned “Department
Head.”

Attribute-Based Access Control (ABAC)

Overview

Fine-grained control based on attributes of:

1. Subject (User): Attributes define the identity and characteristics of the subject e.g.,
name, department, security clearance.
2. Object (Resource): e.g., file metadata like title or author, files, records, tables, printers.
3. Environment: e.g., date, time, location, device type, intranet.

Advantages

High flexibility and expressive power.

Policies defined using logical gates (AND, OR, NOT) and comparisons (<, >, etc.).

Challenges

Performance concerns due to evaluating multiple predicates for each access.

Example

Scenario: An online entertainment store streams movies to users.

Attributes:
Subject: Role (e.g., “Service Consumer”), Age.
Object: Rating, Movie Type.
Environment: Current Date.
Policy Example

Access Control Based on Age:

Users aged 17+ can access movies rated R, PG-13, or G.
Users aged 13–16 can access PG-13 or G.
Users under 13 can access G-rated movies.

Policy Rule:

R1: can_access(S, O, E) ←
(Age(S) ≥ 17 ∧ Rating(O) ∈ {R, PG-13, G}) ∨
(Age(S) ≥ 13 ∧ Age(S) < 17 ∧ Rating(O) ∈ {PG-13, G}) ∨
(Age(S) < 13 ∧ Rating(O) = G)

Membership Example

Premium Members: Access all movies.

Regular Users: Access only old-release movies.

Policy Rule:

R2: can_access(S, O, E) ←
(MembershipType(S) = Premium) ∨
(MembershipType(S) = Regular ∧ MovieType(O) = OldRelease)

Conclusion
Rule 1 ensures access based on age appropriateness for movie ratings.
Rule 2 provides additional access criteria based on membership level and movie
classification.