Discretionary Access Control (DAC)

Overview

In DAC, the resource owner has discretion to determine who can access their resources. This is the most common access control model used in commercial operating systems like Windows and Unix/Linux.

Unix/Linux Permission System

Python DAC Implementation

DAC Strengths and Weaknesses

Interview Questions

1. What is the Trojan horse problem in DAC?

• A malicious program running with user's permissions can copy restricted files to locations accessible by the attacker. Since DAC grants access based on the running user's identity, any program that user runs has the same file access rights.

1. How do Unix file permissions implement DAC?

• Each file has an owner who sets read/write/execute bits for owner, group, and others. The owner can modify these permissions freely (chmod). This is discretionary because the owner decides — no system-wide security policy overrides their choices.

1. Why is DAC considered less secure than MAC?

• DAC allows owners to share access without oversight, information can flow to unauthorized users through copying, and there's no system-enforced security classification. MAC prevents this by enforcing system-wide rules regardless of owner preferences.

1. What is the SUID bit and why is it a security concern?

• SUID makes a program execute with the file owner's permissions (often root). If a SUID program has vulnerabilities (buffer overflow), attackers can escalate privileges to root. Regular SUID audits are essential security hygiene.

1. Compare Windows NTFS ACLs with Unix file permissions.

• Unix: Simple 3-tier model (owner/group/others) with 3 permissions (rwx). Windows NTFS: Rich ACLs with per-user/group entries, granular permissions (13+ types), inheritance, explicit deny, and auditing. NTFS is more flexible but more complex to manage.

Real-World DAC Implementation Examples

Linux File System: The most ubiquitous DAC implementation is the Unix/Linux permission model. Every file and directory has an owner and group, with permission bits for read (r), write (w), and execute (x) across three categories: owner, group, and others. The chmod command lets owners modify these permissions at will — this discretionary nature is the defining characteristic.

This shows: owner (alice) has full access, the developers group can read and execute, and all others are denied access entirely.

Windows NTFS: Windows implements DAC through Access Control Lists (ACLs) that are significantly more granular than Unix permissions. Each file has a Discretionary ACL (DACL) containing Access Control Entries (ACEs) that specify allow or deny permissions for specific users or groups. Permissions include Read, Write, Execute, Delete, Change Permissions, and Take Ownership — over 13 individual permission types.

Database Systems: Relational databases implement DAC through the GRANT and REVOKE SQL statements. Table owners can grant SELECT, INSERT, UPDATE, or DELETE privileges to specific users or roles. This is discretionary because the object owner decides who gets access without requiring administrator involvement.

DAC Security Hardening Strategies

While DAC has inherent limitations, several strategies can reduce risk:

1. Principle of Least Privilege: Grant only the minimum permissions needed for each user's role. Review and revoke unnecessary access regularly.
2. Umask Configuration: Set restrictive default permissions (umask 077) so new files aren't accidentally world-readable.
3. Regular Permission Audits: Script periodic scans for overly permissive files (world-writable, SUID binaries).
4. Group-Based Management: Use groups instead of per-user permissions to simplify administration and reduce errors.
5. Combine with MAC: In high-security environments, layer MAC (SELinux, AppArmor) on top of DAC for defense in depth. DAC handles daily workflow while MAC enforces system-wide security boundaries.