What is LBAC? Lattice-Based Access Control in Casbin

What is LBAC?

LBAC (Lattice-Based Access Control) is a formal model that can enforce both confidentiality and integrity in one framework. This page shows one Casbin formulation: subject and object each have a confidentiality level and an integrity level; the matcher enforces read/write rules on both dimensions.

モデル

[request_definition]
r = sub, subject_confidentiality, subject_integrity, obj, object_confidentiality, object_integrity, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = (r.act == "read" && r.subject_confidentiality >= r.object_confidentiality && r.subject_integrity >= r.object_integrity) || (r.act == "write" && r.subject_confidentiality <= r.object_confidentiality && r.subject_integrity <= r.object_integrity)

Read allowed when subject’s confidentiality and integrity are both ≥ object’s; write allowed when both are ≤ object’s. So confidentiality follows a BLP-like rule and integrity a Biba-like rule, in a single matcher.

Example Requests

The following examples demonstrate how this LBAC implementation evaluates requests:

# Normal read operations (ALLOWED)
admin, 5, 5, file_topsecret, 3, 3, read      # admin (conf:5, int:5) reads file_topsecret (conf:3, int:3) - ALLOWED
manager, 4, 4, file_secret, 4, 2, read       # manager (conf:4, int:4) reads file_secret (conf:4, int:2) - ALLOWED
staff, 3, 3, file_internal, 2, 3, read       # staff (conf:3, int:3) reads file_internal (conf:2, int:3) - ALLOWED
guest, 2, 2, file_public, 2, 2, read         # guest (conf:2, int:2) reads file_public (conf:2, int:2) - ALLOWED

# Read operation violations (DENIED)
staff, 3, 3, file_secret, 4, 2, read         # staff (conf:3, int:3) reads file_secret (conf:4, int:2) - DENIED (conf < obj.conf)
manager, 4, 4, file_sensitive, 3, 5, read    # manager (conf:4, int:4) reads file_sensitive (conf:3, int:5) - DENIED (int < obj.int)
guest, 2, 2, file_internal, 3, 1, read       # guest (conf:2, int:2) reads file_internal (conf:3, int:1) - DENIED (conf < obj.conf)
staff, 3, 3, file_protected, 1, 4, read      # staff (conf:3, int:3) reads file_protected (conf:1, int:4) - DENIED (int < obj.int)

# Normal write operations (ALLOWED)
guest, 2, 2, file_public, 2, 2, write        # guest (conf:2, int:2) writes file_public (conf:2, int:2) - ALLOWED
staff, 3, 3, file_internal, 5, 4, write      # staff (conf:3, int:3) writes file_internal (conf:5, int:4) - ALLOWED
manager, 4, 4, file_secret, 4, 5, write      # manager (conf:4, int:4) writes file_secret (conf:4, int:5) - ALLOWED
admin, 5, 5, file_archive, 5, 5, write       # admin (conf:5, int:5) writes file_archive (conf:5, int:5) - ALLOWED

# Write operation violations (DENIED)
manager, 4, 4, file_internal, 3, 5, write    # manager (conf:4, int:4) writes file_internal (conf:3, int:5) - DENIED (conf > obj.conf)
staff, 3, 3, file_public, 2, 2, write        # staff (conf:3, int:3) writes file_public (conf:2, int:2) - DENIED (both > obj)
admin, 5, 5, file_secret, 5, 4, write        # admin (conf:5, int:5) writes file_secret (conf:5, int:4) - DENIED (int > obj.int)
guest, 2, 2, file_private, 1, 3, write       # guest (conf:2, int:2) writes file_private (conf:1, int:3) - DENIED (conf > obj.conf)

Security Levels

In this implementation, both confidentiality and integrity are represented as integers where higher values indicate higher security levels:

Confidentiality Levels

• Level 1: Public/Unclassified
• Level 2: Confidential
• Level 3: Secret
• Level 4: Top Secret

Integrity Levels

• Level 1: Low integrity (e.g., public data, user-generated content)
• Level 2: Medium integrity (e.g., verified data, trusted sources)
• Level 3: High integrity (e.g., system data, administrative content)
• Level 4: Critical integrity (e.g., security policies, system configuration)

Applicable Scenarios

This LBAC implementation is well-suited for:

• Multi-level security environments
• Applications where both data protection and data accuracy matter

Implementation Notes

• The model implements mandatory access control (MAC) with dual security properties
• System administrators assign security levels
• Access decisions consider both confidentiality and integrity levels
• The model prevents information leakage and data corruption

FAQ

What is the difference between LBAC and MAC? MAC is the category: access is decided by system-assigned labels rather than by the resource owner. LBAC is one way to implement MAC, using a lattice of security levels. The model on this page puts confidentiality and integrity levels in the same lattice.

How is LBAC different from RBAC? RBAC grants permissions to roles that people hold; LBAC grants nothing to roles. Every request carries the subject's and object's levels, and the matcher compares them, so there is no per-user policy to maintain.

Can LBAC be combined with RBAC? Yes. Keep the role checks of RBAC and add the level comparisons to the same matcher; the access control models page shows the same idea for RBAC and ABAC.

Related models

• MAC overview
• Bell-LaPadula (confidentiality)
• Biba (integrity)