Discretionary Access Control (DAC)

The core tenet of DAC is that the creator or owner of a resource (e.g., a file, database record, or directory) holds the ultimate authority to grant or revoke access permissions for other users. This is in direct contrast to centralized, policy-driven models like Mandatory Access Control (MAC). Ownership is typically established at the moment of resource creation. The owner can delegate their administrative rights, allowing other users to manage the access control list (ACL) for that specific object.

DAC is most commonly implemented using Access Control Lists (ACLs). An ACL is a table attached to a resource that enumerates which subjects (users, groups, processes) are permitted to perform which operations (read, write, execute).

• Each entry in an ACL specifies a subject and a set of permissions.
• Operating systems like Unix/Linux and Windows NTFS use ACLs for file system security.
• This provides a direct, object-centric view of permissions, answering the question: "Who can access this specific file?"

DAC is highly flexible and adaptable to dynamic environments. Owners can grant permissions on a per-user basis, enabling fine-grained control. This model supports easy delegation of authority, where an owner can grant another user the ability to modify the ACL, effectively sharing administrative control. However, this flexibility is a double-edged sword; it can lead to permission sprawl and inconsistencies if not carefully managed, as there is no central authority enforcing a uniform security policy.

A key characteristic—and a significant limitation—of DAC is the absence of a centralized, mandatory security policy. Security is enforced at the discretion of individual resource owners. This makes DAC inherently vulnerable to Trojan horse attacks, where malicious code executes with the permissions of the user who runs it, potentially accessing all files that user owns or has permissions to. It contrasts with Mandatory Access Control (MAC), where a system-wide policy, not user discretion, governs all access decisions.

DAC is the foundational model for most mainstream operating systems and many network file systems.

• Unix/Linux File Permissions: The classic owner-group-others (rwx) model is a simple form of DAC.
• Windows NTFS Permissions: Uses detailed ACLs allowing for complex allow/deny entries for users and groups.
• Traditional Database Systems: Table or row-level permissions often granted by the database object owner.
• Personal File Sharing: When a user shares a document via a cloud service (like a shared link with edit rights), they are exercising discretionary control.

DAC differs fundamentally from other enterprise models:

• vs. Role-Based Access Control (RBAC): RBAC assigns permissions to roles, not individual users or objects. Access is based on a user's job function, simplifying management in large organizations. DAC is object-owned; RBAC is administrator-managed.
• vs. Attribute-Based Access Control (ABAC): ABAC makes decisions using policies that evaluate attributes of the user, resource, action, and environment (e.g., time > 9:00 AM). DAC decisions are based solely on static lists maintained by an owner, with no environmental context.

Mandatory Access Control (MAC) is a non-discretionary security model where a central authority, not the resource owner, defines and enforces all access decisions. Access is determined by comparing security labels (e.g., classifications like 'Top Secret', compartments) assigned to both subjects (users/processes) and objects (files/resources). This model is common in military and government systems where data confidentiality is paramount.

• Key Contrast to DAC: In MAC, users cannot override or transfer access, even if they own the resource.
• Implementation: Often uses a reference monitor to enforce a system-wide security policy.
• Example: A file labeled 'Secret' can only be accessed by a process with a 'Secret' or higher clearance, regardless of which user created the file.

Role-Based Access Control (RBAC) is an access control model where permissions are assigned to roles, and users are assigned to these roles, rather than having permissions assigned directly. It centralizes administration by grouping common job functions.

• Core Concept: Permissions are associated with roles (e.g., 'Editor', 'Viewer', 'Admin'), and users inherit permissions by being assigned one or more roles.
• Contrast to DAC: RBAC is policy-centric and typically managed by administrators, reducing the ad-hoc, user-driven permission grants characteristic of pure DAC.
• Hierarchies: Supports role inheritance (a 'Senior Editor' role may include all permissions of the 'Editor' role).
• Primary Use Case: Enterprise environments with many users and well-defined job functions, simplifying audit and compliance.

Attribute-Based Access Control (ABAC) is a dynamic authorization model that evaluates access requests based on attributes of the user, resource, action, and environment against a set of policies.

• Mechanism: Policies use boolean logic (e.g., IF user.department == 'Finance' AND resource.classification == 'Internal' AND time.now < 18:00 THEN ALLOW).
• Granularity: Enables extremely fine-grained permissions based on multiple contextual factors.
• Contrast to DAC: While DAC decisions are based on identity lists (ACLs), ABAC decisions are based on a rich set of evaluable attributes and policies, allowing for more context-aware rules (e.g., access only from corporate IP ranges).
• Standard: Often implemented using the eXtensible Access Control Markup Language (XACML) and policy engines like Open Policy Agent (OPA).

An Access Control List (ACL) is the primary technical mechanism for implementing Discretionary Access Control (DAC). It is a list attached to a system object (file, directory, network port) that specifies which users or system processes are granted access, and what operations (read, write, execute) they are allowed.

• Structure: Each entry in an ACL typically specifies a subject (user, group) and a set of permissions.
• Types: Filesystem ACLs (e.g., in NTFS, POSIX) and Network ACLs (e.g., firewall rules).
• DAC Implementation: In a DAC model, the resource owner has the discretion to modify the ACL for that resource.
• Example: A file's ACL might list: User:Alice: Read, Write; Group:Engineering: Read; Others: None.

The Principle of Least Privilege (PoLP) is a foundational security axiom stating that every user, process, or system should operate using the minimum level of access rights necessary to perform its legitimate function. It is a guiding philosophy for designing all access control systems, including DAC.

• Application to DAC: In a DAC environment, resource owners should grant only the specific permissions needed, rather than broad 'full control' access.
• Goal: To limit the potential damage from accidents, errors, or malicious use of credentials.
• Related Practice: Credential Scoping and Just-in-Time (JIT) Access are operational implementations of this principle, dynamically providing elevated privileges only when strictly required.

Capability-Based Security is an access control model where authority to access an object is embodied in an unforgeable token, called a capability. Possession of the capability is both the designation of the object and the permission to access it in a specified manner.

• Key Difference from ACLs: In ACL-based systems (like DAC), the system checks a central list to see if a subject is allowed. In capability systems, the subject presents the token as proof of authority.
• Properties: Capabilities are unforgeable and can be delegated by passing the token, aligning with DAC's discretionary nature but with stronger inherent security against tampering.
• Analogy: A physical key to a specific door is a capability; having the key grants access, and you can lend it to someone else (delegate).
• Use in Computing: Found in some microkernel operating systems and as a theoretical model for secure distributed systems.