Tutorial 3.10: Discretionary Access Control (DAC)

Learning Objectives

After completing this tutorial, you should be able to:

• Define Discretionary Access Control (DAC) and its core principle of owner discretion.
• Explain the role of ownership and how it grants authority to control access.
• Describe Access Control Lists (ACLs) and capability lists as implementation mechanisms for DAC.
• Compare and contrast ACLs and capability lists.
• Analyze DAC implementations in UNIX (file permissions) and Windows (NTFS ACLs).
• Evaluate the advantages and limitations of DAC, including its vulnerability to Trojan horse attacks.
• Identify security risks and propose countermeasures for DAC-based systems.
• Design a DAC policy for a given scenario, using appropriate mechanisms.
• Assess real-world DAC deployments and recommend improvements.

Overview

In Tutorial 3.9, we introduced the four major access control models. Among them, Discretionary Access Control (DAC) is the most common and widely understood. It is the model used by most operating systems, file systems, and applications. DAC is intuitive: the owner of a resource has the discretion to decide who can access it and with what permissions. This flexibility makes DAC appealing for personal computing and many enterprise environments, but it also introduces security risks, particularly the potential for malicious users to trick others into granting access to sensitive resources.

This tutorial provides a comprehensive exploration of DAC. We begin by defining DAC and its foundational principle of owner discretion. We discuss the concept of ownership and how it is established, including the ability to delegate permissions through groups and inheritance. We then examine the two primary mechanisms for implementing DAC: Access Control Lists (ACLs) and capability lists. ACLs are the dominant mechanism, attached to objects and listing subjects with their permissions. Capability lists are attached to subjects and list objects they can access.

We take a deep dive into real-world DAC implementations. We examine the classic UNIX file permission model (owner, group, others, and the read/write/execute bits) and how it has been extended with POSIX ACLs. We then explore the more sophisticated NTFS ACLs used in Windows, which support fine-grained permissions, inheritance, and audit entries.

We also analyze the advantages of DAC—its simplicity, flexibility, and user control—along with its limitations. A major vulnerability is the Trojan horse problem: a user can execute a program that, under the user's own permissions, accesses and modifies files, potentially causing damage. We discuss countermeasures such as the principle of least privilege, user education, and the use of additional security controls (e.g., antivirus, application whitelisting).

The tutorial concludes with case studies illustrating DAC in a small business environment and a university research lab, demonstrating how DAC can be effectively deployed and where its limitations become apparent. By the end of this tutorial, you will have a thorough understanding of DAC, enabling you to design, implement, and manage DAC-based access control systems, as well as recognize when DAC may be insufficient and other models (MAC, RBAC, ABAC) should be considered.

1. Introduction to Discretionary Access Control

1.1 Definition and Core Principle

Discretionary Access Control (DAC) is an access control model in which the owner of a resource (object) has the discretion—the authority—to determine who can access that resource and with what permissions. The owner can grant, revoke, or change permissions at their discretion, subject to any system-wide policies or constraints.

The term "discretionary" emphasizes that the owner has control and can make decisions based on their judgment. This is in contrast to Mandatory Access Control (MAC), where a central authority imposes labels and rules that cannot be overridden by the owner.

1.2 Historical Context

DAC has been a part of computing since the early days of time-sharing systems. The UNIX operating system, developed in the 1970s, introduced a simple DAC model based on the user-owner, group, and others permissions. This model was extended in the 1980s with Access Control Lists (ACLs) in systems like Sun's Network File System (NFS) and later in Windows NT. DAC remains the default access control model in most general-purpose operating systems.

1.3 The Role of Ownership

In DAC, every object (e.g., file, directory, printer) has an owner. The owner is typically the user who created the object, but ownership can be transferred or assigned by a privileged user (e.g., administrator). The owner has the authority to set permissions on the object. This authority includes:

• Granting read, write, execute, or other permissions to specific users or groups.
• Revoking permissions from users or groups.
• Changing the ownership of the object (often restricted to administrators).
• Deleting the object.

In many systems, the owner is also the only user who can modify the permissions (unless overridden by an administrator). This centralizes control but can lead to inconsistencies if owners are not diligent.

2. Ownership and Discretion

2.1 Establishing Ownership

In most systems, the creator of an object becomes its owner. For example, when a user creates a file in UNIX, the user's UID (User ID) is associated with the file as its owner. Similarly, in Windows, the creator gets ownership by default. However, an administrator can take ownership or transfer ownership using special tools.

2.2 Owner's Discretion

The owner can set permissions according to their judgment. The discretion includes:

• Granting access: The owner can add users or groups to the object's ACL, specifying the allowed operations.
• Revoking access: The owner can remove users or groups from the ACL.
• Changing permissions: The owner can modify the types of access (e.g., changing read-only to read-write).
• Delegating control: The owner can grant "change permissions" or "take ownership" rights to others, effectively delegating their authority.

2.3 Groups and Inheritance

To simplify administration, DAC systems often support groups. Permissions can be granted to a group, and all members of that group inherit those permissions. This is efficient for organizational structures (e.g., a "finance" group needing access to financial files). Inheritance allows permissions to propagate from parent directories to child objects, reducing the need to set permissions on every object individually.

2.4 Ownership Transfer

In some systems, ownership can be transferred to another user. This is typically restricted to administrators or users with the "take ownership" privilege. Transferring ownership is useful when a user leaves an organization or when a resource needs to be managed by another individual.

3. Access Control Lists (ACLs)

3.1 What is an ACL?

An Access Control List (ACL) is a list of entries attached to an object (e.g., a file or directory). Each entry, called an Access Control Entry (ACE), specifies a subject (user or group) and the permissions granted or denied to that subject. ACLs are the primary mechanism for implementing DAC in modern operating systems.

3.2 Structure of an ACL Entry

A typical ACE contains:

• Subject identifier: Usually a user ID or group ID.
• Permission flags: A set of rights (e.g., read, write, execute, delete, modify permissions).
• Type: Allow or Deny (some systems support both).
• Inheritance flags: Whether the entry applies to children of the object.

3.3 Types of ACLs

• Discretionary ACL (DACL): Specifies which users/groups are allowed or denied access. This is the ACL controlled by the owner.
• System ACL (SACL): Specifies which access attempts to audit (success and/or failure). SACLs are typically managed by administrators for auditing purposes.

3.4 ACL Evaluation

When a subject requests access to an object, the system evaluates the ACL to determine if the subject has the required permissions. The evaluation process typically follows these steps:

1. If there is a "Deny" entry for the subject or a group they belong to, the access is denied (unless there is an explicit allow with higher precedence, which is uncommon).
2. Otherwise, if there is an "Allow" entry for the subject or a group, the access is allowed.
3. If no matching entries exist, access is denied by default (fail-safe).

The order of evaluation depends on the system. In Windows, deny entries take precedence over allow entries. In UNIX ACLs, the order is more nuanced and can be configured.

3.5 Example ACL

Consider a file project.docx with the following ACL in Windows:

• Owner: Alice (Full Control)
• Administrators: Full Control
• Bob: Read, Write
• Finance Group: Read
• Charlie: Deny Read

In this case, Charlie, even if a member of Finance Group, would be denied read access due to the explicit deny.

4. Capability Lists

4.1 What is a Capability List?

A capability list is a list attached to a subject that specifies the objects that the subject can access and the permissions allowed on each. This is the inverse of an ACL: rather than each object listing who can access it, each subject lists which objects they can access.

4.2 Capability-Based Security

Capability lists are the foundation of capability-based security, an alternative to ACL-based systems. Capabilities are often implemented as tickets or tokens that the subject presents to the object. The system verifies the capability's authenticity before granting access.

Examples of capability-based systems include the Amoeba distributed operating system, IBM's System/38, and more recently, the Google Fuchsia operating system. Capabilities are also used in some file systems (e.g., network file systems that support delegation).

4.3 Advantages of Capability Lists

• Centralized subject management: It is easy to see what a subject can access by examining its capability list.
• Delegation: Capabilities can be passed from one subject to another, allowing controlled delegation of authority.
• Revocation: Revoking a capability is easier if the capability is a token that can be invalidated.

4.4 Disadvantages of Capability Lists

• Scalability: For large systems with many objects, capability lists can become very large and difficult to manage.
• Complexity: Implementing capability-based security requires careful design to prevent forgery and ensure proper revocation.
• Less common: Most mainstream operating systems use ACLs, so interoperability can be challenging.

4.5 Comparison: ACL vs. Capability Lists

Aspect	ACL	Capability List
Attached to	Object	Subject
Scope	All subjects for a given object	All objects for a given subject
Administration	Object owner manages permissions	Subject (or authority) manages capabilities
Delegation	Requires modifying ACL on object	Easier: capability can be passed
Revocation	Simple: remove entry from ACL	More complex: need to invalidate capability
Common use	Mainstream OS (Unix, Windows)	Research systems, specialized environments

5. DAC in Practice: UNIX Permissions

5.1 Classic UNIX File Permissions

The classic UNIX file permission model is a form of DAC. Each file and directory has:

• Owner (user): The user who owns the file.
• Group: A group associated with the file.
• Permissions: A set of nine bits: three sets (owner, group, others) of three bits (read, write, execute).

Permissions are displayed as a string like -rwxr-x---, which means:

• rwx for owner: read, write, execute
• r-x for group: read, execute
• --- for others: no permissions

5.2 Limitations of Classic UNIX Permissions

The classic model has limitations:

• Only one group: A file can be associated with only one group, making it hard to share with multiple groups.
• Coarse granularity: Only three categories (owner, group, others), lacking per-user granularity.
• No deny: Only allows (rwx) bits; no explicit deny, so the only way to deny is to omit permissions.

5.3 POSIX ACLs (Extended ACLs)

To overcome these limitations, POSIX ACLs were introduced. They allow:

• Multiple user entries (e.g., user:alice:rw).
• Multiple group entries.
• Default ACLs for directories (inheritance).
• Mask entries to limit effective permissions.

POSIX ACLs are widely supported in Linux and other UNIX-like systems. They are managed with commands like setfacl and getfacl.

Example: setfacl -m u:bob:rw file.txt grants Bob read/write access.

5.4 Security Considerations in UNIX DAC

• Setuid/Setgid: Programs with setuid can run with the owner's permissions, which can introduce privilege escalation risks.
• Sticky bit: On directories, the sticky bit ensures only the owner can delete files in the directory, which is useful for shared directories.
• Umask: The default permission mask determines permissions for newly created files, which is a security setting.

6. DAC in Practice: Windows NTFS ACLs

6.1 NTFS Security Model

Windows NTFS (New Technology File System) implements a rich DAC model using ACLs. Each file and directory has a security descriptor that includes a DACL and a SACL. The DACL contains ACEs that specify allow or deny permissions for users and groups.

6.2 ACE Structure

An NTFS ACE typically includes:

• SID (Security Identifier): The SID of the user or group.
• Permissions: A set of rights (e.g., Read, Write, Read & Execute, Modify, Full Control).
• Type: Allow or Deny.
• Flags: Inheritance settings (apply to this folder, subfolders, files).

6.3 Inheritance and Propagation

NTFS ACLs support inheritance, allowing permissions to be inherited from parent directories. Inheritance can be set at the folder level, and files or subfolders can inherit or override these permissions. This simplifies management significantly.

6.4 Effective Permissions

Effective permissions are the actual permissions a user has on an object. They are determined by combining:

• Explicit permissions assigned directly to the user or group.
• Inherited permissions from parent objects.
• Deny entries override Allow entries.

The Windows security model also supports "effective permissions" tools that help administrators determine the net permissions for a given user.

6.5 Security Implications

• Granular permissions: NTFS provides a wide range of permissions (e.g., Traverse Folder, List Folder, Read Attributes, Write Attributes).
• Deny entries: Explicit deny overrides allow, but careful use is recommended to avoid complexity.
• Ownership: The owner can always change the DACL, even if they don't have explicit permissions to do so (this is a system-level privilege).
• Auditing: SACLs allow logging of successful and failed access attempts.

7. Advantages and Limitations of DAC

7.1 Advantages

• Intuitive: Owners understand that they can control who accesses their files.
• Flexible: Owners can grant access on a case-by-case basis, accommodating ad-hoc sharing needs.
• Low administrative overhead: For small to medium systems, DAC requires minimal central administration—owners manage their own resources.
• Widely supported: DAC is implemented in virtually all commercial operating systems and applications.
• Easy to implement: The model is simple and does not require complex labeling or attribute infrastructure.

7.2 Limitations

• Trojan horse vulnerability: Users can be tricked into executing malicious programs that operate with their permissions, potentially damaging files or leaking data.
• Inconsistency: Different owners may set permissions differently, leading to inconsistent security policies across an organization.
• Poor scalability: In large organizations, managing permissions on a per-file or per-directory basis becomes unmanageable.
• No centralized policy enforcement: DAC does not enforce a global security policy; owners can override it.
• Limited access revocation: Revoking access can be difficult if permissions are inherited or if there are many nested groups.
• Lack of mandatory information flow control: DAC does not prevent users from sharing information with unauthorized parties (e.g., copying a confidential file to a shared location).

8. Security Vulnerabilities and Countermeasures

8.1 The Trojan Horse Problem

A Trojan horse is a malicious program that appears to be benign but performs harmful actions. In a DAC system, if a user executes a Trojan horse, the program runs with the user's permissions. It can then read, modify, or delete any files the user has access to, potentially causing significant damage or data theft.

8.2 Other Vulnerabilities

• Permission escalation: Users may exploit setuid/setgid programs or misconfigured permissions to gain higher privileges.
• Race conditions: In multi-threaded systems, attackers might exploit timing windows to gain unauthorized access.
• Inheritance misconfiguration: Incorrect inheritance settings can lead to unintended access.
• Overly permissive defaults: Default permissions (e.g., world-readable files) can expose data.

8.3 Countermeasures

• Least privilege: Grant users only the permissions they need. Avoid using administrative accounts for routine tasks.
• User education: Train users to recognize phishing and social engineering attacks that deliver Trojans.
• Application whitelisting: Allow only approved programs to run, reducing the risk of malicious code execution.
• Antivirus and endpoint protection: Detect and block known malware.
• Regular audits: Review permissions and access logs to detect anomalies.
• Use of additional controls: Combine DAC with other models (e.g., RBAC for enterprise applications, MAC for high-security environments).

9. Case Studies

9.1 Case Study: Small Business File Sharing

Background: A small marketing firm with 20 employees uses a Windows file server to share documents. The file server uses NTFS permissions. Each department has its own shared folder.

Implementation:

• Each department folder is owned by the department manager.
• Managers grant permissions to their team members and control access.
• Inheritance is used to simplify permissions: the departmental folder has a default ACL that applies to all files within.
• Some cross-departmental projects have dedicated folders with ACLs granting access to specific members from different teams.

Outcome: The DAC model works well because the organization is small and managers are responsible. However, as the company grows, they may need to adopt RBAC to manage complexity.

9.2 Case Study: University Research Lab

Background: A university research lab has multiple research groups working on various projects. The lab uses Linux with POSIX ACLs to manage file permissions on a shared storage system.

Implementation:

• Each research group has its own directory.
• Group members are added to a group (e.g., group_ai, group_robotics).
• ACLs are used to grant read/write access to the group and possibly read-only to others.
• Some projects involve collaboration between groups; ACLs are adjusted to grant access to specific users from other groups.
• Default ACLs on project directories ensure that new files inherit the correct permissions.

Challenges: As the lab grows, managing ACLs manually becomes cumbersome. Additionally, some users may inadvertently share sensitive data with outside collaborators due to overly permissive ACLs. The lab is considering moving to ABAC with attributes (e.g., project membership, clearance) to improve manageability.

10. Summary and Transition

This tutorial provided a comprehensive exploration of Discretionary Access Control (DAC). We defined DAC as a model where the owner of a resource has discretion over access, and we discussed the role of ownership, groups, and delegation. We examined the two primary DAC mechanisms: Access Control Lists (ACLs) and capability lists, comparing their strengths and weaknesses.

We took a deep dive into real-world implementations: the classic UNIX file permissions and their extension with POSIX ACLs, and the sophisticated NTFS ACLs in Windows. We analyzed the advantages of DAC—simplicity, flexibility, and low administrative overhead—and its limitations, particularly the Trojan horse problem and the difficulty of enforcing consistent policies across large organizations. We discussed countermeasures such as least privilege, user education, and application whitelisting.

The case studies illustrated DAC in a small business and a university research lab, demonstrating both its effectiveness and its scalability challenges.

DAC is the most accessible and widely used access control model, but it is not suitable for all environments. In the next tutorial, Tutorial 3.11, we will examine Mandatory Access Control (MAC), which takes a more rigid, centralized approach based on security labels and classifications, providing stronger security guarantees for high-risk environments.

Quiz

Answer the following questions to check your understanding. Click the "Answer" button to reveal the solution.

Exercises

These exercises are designed to help you apply the concepts from this tutorial. Attempt each exercise before revealing the sample solution.

Homework

These homework questions require deeper analysis, research, and application. Answer each question comprehensively.

Summary

This tutorial provided a comprehensive exploration of Discretionary Access Control (DAC). We defined DAC as a model where the owner of a resource has the discretion to control access, making it intuitive and flexible. We discussed the role of ownership, groups, and delegation, and examined the two primary mechanisms for implementing DAC: Access Control Lists (ACLs) and capability lists. ACLs are the dominant mechanism, attached to objects and listing subjects with their permissions, while capability lists are attached to subjects.

We analyzed real-world implementations: the classic UNIX file permission model (with its three sets: owner, group, others) and its extension with POSIX ACLs, which allow multiple users and groups and inheritance. We also explored the rich NTFS ACLs in Windows, which support fine-grained permissions, inheritance, and explicit deny entries.

We evaluated the advantages of DAC—simplicity, flexibility, and low administrative overhead—and its limitations, including the Trojan horse vulnerability, policy inconsistency, and scalability challenges. We discussed countermeasures such as least privilege, user education, application whitelisting, and the use of complementary controls like auditing and monitoring.

The case studies illustrated DAC in small business and research lab environments, highlighting its effectiveness and the challenges that arise as organizations grow.

DAC is the foundation of access control in most systems, but it is not sufficient for high-security environments or large enterprises with complex governance needs. In the next tutorial, Tutorial 3.11, we will examine Mandatory Access Control (MAC), a more rigid model based on security labels that provides stronger guarantees but requires centralized administration.

© 2026 COMP400 – Computer and Network Security • School of Computing and Information Systems, TrustOpen University • Unit 3: Authentication and Access Control