Simulation Lab 13.1: Module 13 Using Discretionary Access Control

Simulation Lab 13.1: Mastering Discretionary Access Control in Module 13

Discretionary Access Control (DAC) forms the bedrock of modern file system security and collaborative resource sharing. In Simulation Lab 13.1 of Module 13, you move beyond theoretical definitions to implement, test, and critically analyze this fundamental security model. This hands-on experience is crucial for understanding how permissions are not just set by a central authority but are discretionarily granted by the very owners of data, shaping the security posture of everything from personal computers to enterprise servers. This lab transforms abstract concepts of "read," "write," and "execute" into tangible control over a simulated digital environment.

The Core Philosophy: What is Discretionary Access Control?

At its heart, Discretionary Access Control is a policy that determines access based on the identity of the user and the permissions explicitly assigned by the owner of an object (like a file or directory). The key word is "discretionary." The system administrator may set the overall framework, but the individual who creates a file has the discretion to decide who else can read, modify, or execute it. This contrasts sharply with Mandatory Access Control (MAC), where a central security policy, often based on security labels (like "Top Secret" or "Confidential"), strictly dictates access, overriding the owner's wishes.

In a DAC system, the fundamental relationship is between:

• Subjects: Active entities, typically users or processes acting on behalf of a user.
• Objects: Passive entities requiring protection, such as files, directories, printers, or database records.
• Permissions: The specific operations (read, write, execute) a subject is allowed to perform on an object.

The mechanism that enforces this is most commonly the Access Control List (ACL). An ACL is a list attached to an object that specifies which subjects have what permissions. For example, a file's ACL might state: Alice: read, write; Bob: read; Charlie: none. The operating system's reference monitor consults this list every time a subject attempts an operation on the object.

Lab 13.1 Walkthrough: From Commands to Comprehension

Simulation Lab 13.1 provides a controlled, command-line environment (often mimicking Linux/Unix chmod and chown commands or Windows icacls) to build this understanding step-by-step.

Step 1: Environment Setup and Ownership. You begin by creating a user account for yourself and several colleague accounts (e.g., alice, bob, charlie). You then create a project directory, say Project_Alpha, and a sensitive file within it, confidential_plan.txt. By default, as the creator, you are the owner. The lab first ensures you understand this default ownership and the initial, restrictive permissions (often only the owner has full access).

Step 2: Implementing the ACL – Granting Discretionary Permissions. This is the core of the lab. Using a command like chmod (change mode) or its graphical equivalent, you modify the ACL.

• You grant bob read access to confidential_plan.txt because he needs to be informed.
• You grant charlie read and write access because he is a co-author.
• You create a subdirectory public_assets and set its permissions to allow all project members (alice, bob, charlie) to read and execute (traverse the directory), but only you and charlie can write (add/remove files).

You learn the symbolic (e.g., u+rwx,g+rx,o-rwx) or octal (e.g., 750) notation that concisely represents these permission sets for owner (u), group (g), and others (o). The lab emphasizes that you, the owner, are making these discretionary choices.

Step 3: Testing and Validation – The Proof is in the Access. The lab includes a verification phase. You switch user contexts (using su - alice or runas) to simulate logging in as bob and charlie.

• As bob, you successfully cat (read) the confidential file but fail to edit it. You can list the public_assets directory but cannot add a new file to it.
• As charlie, you can both read and edit confidential_plan.txt and also add files to public_assets.
• As a fourth user, david, who is not in the project group and has no explicit permissions, all access attempts fail.

This step cements the cause-and-effect relationship: the permissions you set directly dictate what others can do.

Step 4: The Power and Peril of the "Write" Bit on Directories. A critical lesson in the lab is the special meaning of permissions on directories.

• Read (r): Allows listing the filenames within the directory.
• Write (w): Allows creating, deleting, and renaming files within that directory. Crucially, if you have write permission on a directory, you can delete files inside it even if you have no write permission on the file itself. This is a classic DAC vulnerability the lab highlights.
• Execute (x): Allows traversing (entering) the directory and accessing files/subdirectories within it. Without execute, you cannot access any file inside, even if you know its name and have read permission on the file.

You might perform an experiment: give bob write permission on Project_Alpha but not on confidential_plan.txt. Then, as bob, you can delete confidential_plan.txt—a devastating action that bypasses the file's own ACL. This illustrates that directory permissions are paramount and often misunderstood.

Step 5: Group-Based DAC – Scaling Discretion. Managing individual user permissions for large teams is inefficient. The lab introduces groups as a scalable DAC mechanism. You create a group project_alpha_team, add alice, bob, and charlie to it, and then set directory permissions using the group bit (g+rwx). Now, managing team access is as simple as adding or removing users from the group. The owner's discretion is applied at the group level, a powerful abstraction.

Scientific and Security Implications of the DAC Model

The lab’s exercises reveal the inherent characteristics and trade-offs of Discretionary Access Control.

Strengths:

• Flexibility and Decentralization: It supports the dynamic, collaborative nature of most organizations. Owners can quickly grant access as project needs change without involving a central security administrator.
• Ease of Use and Understanding: The concept of

Ease of Use and Understanding:** The concept of ownership and permissions is intuitive, aligning with everyday notions of privacy and control. This simplicity lowers the barrier to entry for secure file management.

Weaknesses:

• Vulnerability to Insider Threats: The "discretionary" nature means legitimate users (like charlie in the lab) can inadvertently or maliciously compromise security by sharing credentials or misconfiguring permissions. A single compromised account can cascade into a systemic breach.
• Misconfiguration Risks: As demonstrated by the directory-write vulnerability, DAC's flexibility creates complex permission matrices prone to human error. Overly permissive settings (e.g., granting 777 to a directory) can silently undermine security, while overly restrictive settings cripple collaboration.
• Lack of Centralized Enforcement: Without a central authority, owners may overlook access audits or fail to promptly revoke permissions when roles change. This decentralization, while efficient, creates blind spots in compliance and risk management.
• Inheritance Challenges: DAC models often struggle with granular inheritance hierarchies. For instance, ensuring a new file inherits a parent directory's secure permissions by default requires explicit configuration, which is frequently overlooked.

Conclusion

The DAC lab serves as a microcosm of the broader security landscape, illustrating how discretionary access control balances operational agility against inherent risks. While DAC enables the fluid, user-driven collaboration essential in modern environments, its reliance on individual discretion necessitates vigilant discipline. The experiments with directory permissions, group management, and user roles underscore that security is not merely a technical configuration but a continuous process of education, auditing, and refinement. Ultimately, mastering DAC is not about eliminating vulnerabilities but understanding their origins—empowering administrators to wield flexibility responsibly while mitigating the perils of misplaced trust. In an era where human error remains the weakest link, this hands-on reinforcement of cause-and-effect is indispensable for building resilient systems.