Simulation Lab 13.1: Module 13 Using Discretionary Access Control

Simulation Lab 13.1: Module 13 Using Discretionary Access Control is a critical hands-on exercise for anyone studying cybersecurity, system administration, or network management. This module moves beyond theoretical concepts and forces you to get your hands dirty with the real-world mechanics of how systems decide who can access what, and under what conditions. By the time you finish this simulation, you will have a practical, muscle-memory understanding of discretionary access control (DAC) that will serve you well in exams, job interviews, and actual production environments.

What Is Discretionary Access Control?

Before diving into the lab, it’s essential to understand the core principle. Discretionary Access Control is a model where the owner of a resource—whether it’s a file, a directory, or a system process—has the discretion to grant or deny access to other subjects, such as users or groups. This is in contrast to Mandatory Access Control (MAC), where rules are enforced by a central authority like an operating system kernel, and the owner has little to no say.

In DAC, the three pillars are:

• Subject: The entity requesting access (e.g., a user, a program).
• Object: The resource being protected (e.g., a file, a folder).
• Access Matrix: A table or list defining what permissions the subject has on the object (e.g., read, write, execute).

The owner of the object sets these permissions. On Linux systems, this is managed through commands like chmod and chown, while on Windows, it involves the GUI-based Security tab or PowerShell cmdlets. This discretionary power is both a strength and a potential weakness, which is exactly what Module 13 explores.

Understanding Module 13 in the Simulation Lab

Simulation Lab 13.Because of that, 1 is designed to take you through a structured scenario where you must configure DAC policies to meet specific security requirements. Here's the thing — the lab typically provides a virtual machine or a networked environment where you have multiple users and files. Your job is to see to it that the right people have the right level of access, and the wrong people are kept out.

Objectives of the Module

The primary goals of this simulation are:

1. Identify and configure file ownership. You will learn to change the user and group owner of files using commands like chown and chgrp.
2. Apply and modify permissions. You will use symbolic and numeric modes with chmod to set read (r), write (w), and execute (x) permissions for the owner, group, and others.
3. Manage access through groups. You will create and assign users to groups to control access collectively rather than individually.
4. Verify access controls. You will switch between user accounts to test if the permissions you set are working as intended.

Environment and Tools Used

The lab usually runs on a Linux distribution like Ubuntu or CentOS, though some versions use a Windows Server environment. Common tools you will encounter include:

• The terminal or command prompt.
• The ls -l command to view file permissions.
• Text editors like nano or vim to create files for testing.
• User management commands like useradd, usermod, and groupadd.

Step-by-Step Walkthrough of Simulation Lab 13.1

Let’s break down the typical workflow you will follow in this simulation That alone is useful..

Step 1: Setting Up the Lab Environment

Your first task is to log into the provided virtual machine as the root or administrator user. You need to ensure the environment is clean and that you understand the initial state. Check which users exist and what groups they belong to by running:

cat /etc/passwd
cat /etc/group

This gives you a list of all users and groups. Note that the lab might ask you to create specific users. Here's one way to look at it: you might need to create alice, bob, and charlie using:

sudo useradd -m -s /bin/bash alice
sudo useradd -m -s /bin/bash bob
sudo useradd -m -s /bin/bash charlie

You will also likely need to set initial passwords for these users The details matter here..

Step 2: Assigning File Ownership and Permissions

Now, create a set of test files and directories. Suppose the lab requires you to protect a directory called project_data:

mkdir project_data
touch project_data/file1.txt project_data/file2.txt

The goal might be to give alice full ownership and permissions, while bob can only read the files, and charlie has no access at all Not complicated — just consistent..

First, change the owner to alice:

sudo chown alice:alice project_data

Next, set the permissions so that the owner (alice) has read, write, and execute (rwx), the group has read-only (r--), and others have no access (---). You can do this with:

chmod 750 project_data

To verify, run ls -l project_data. You should see something like:

drwxr-x--- 2 alice alice 4096 ... project_data

This means:

• Owner (alice): rwx (7)
• Group (alice): r-x (5)
• Others: --- (0)

Step 3: Configuring Group Access

In many real-world scenarios, you don’t want to manage permissions user by user. This is where groups come

into play. Instead of assigning individual permissions to each user, you can create a group that grants shared access to specific files or directories Not complicated — just consistent..

Start by creating a group called project_team:

sudo groupadd project_team

Then add users to this group:

sudo usermod -aG project_team bob
sudo usermod -aG project_team charlie

Now, change the group ownership of the project_data directory to project_team:

sudo chgrp project_team project_data

Set permissions so that the owner (alice) retains full access, members of project_team have read and execute access, and everyone else is denied:

chmod 750 project_data

Verify the changes with ls -l:

drwxr-x--- 2 alice project_team 4096 ... project_data

Now both bob and charlie can deal with into the directory and read its contents, while alice maintains full control.

Step 4: Testing Access as Different Users

After configuring permissions, it's crucial to test them from each user's perspective. Switch to the bob user and attempt to access the files:

su - bob
cat project_data/file1.txt

If permissions are set correctly, bob should be able to read the file. Now try switching to charlie and repeat the command:

su - charlie
cat project_data/file1.txt

This should result in a "Permission denied" error, confirming that access restrictions are working as expected Small thing, real impact. Took long enough..

Step 5: Advanced Permission Scenarios

Some labs may require more complex setups. Here's a good example: you might need to allow charlie to write to a specific file while keeping other files restricted. In such cases, you can set individual file permissions:

sudo setfacl -m u:charlie:rw project_data/file1.txt

This uses Access Control Lists (ACLs) to grant charlie read and write access to a single file, overriding the directory's general permissions.

Conclusion

Linux file permissions form the backbone of system security, ensuring that users can only access resources appropriate to their roles. On the flip side, through careful management of ownership, group memberships, and permission settings, administrators can create strong access controls that protect sensitive data while enabling collaboration. Whether you're managing a simple lab environment or a complex enterprise system, mastering these fundamentals is essential for maintaining both functionality and security in Unix-like operating systems.

Key Takeaways for Lab Administrators

When managing Linux systems in educational or research lab environments, several best practices should guide your approach to file permissions. Also, first, always follow the principle of least privilege—grant only the minimum permissions necessary for users to complete their tasks. This minimizes the risk of accidental or intentional data exposure.

Second, regularly audit your permission structures. Consider this: over time, as projects evolve and users come and go, permission configurations can become convoluted. Periodic reviews help identify and rectify overly permissive settings or orphaned files with unclear ownership.

Third, document your permission strategy. In practice, while Linux provides reliable access controls, their effectiveness depends on consistent application. Maintain clear documentation of group purposes, permission rationale, and any exceptions to standard policies Turns out it matters..

Troubleshooting Common Issues

Even with careful planning, administrators frequently encounter challenges. Users reporting "Permission denied" errors often stem from incorrect group membership—remember that users must log out and back in for group changes to take effect. Additionally, directory permissions require execute bits to allow traversal, a common oversight when configuring read-only access.

Another frequent issue involves conflicting permissions between files and parent directories. A file with open permissions inside a restricted directory remains inaccessible because users cannot enter the directory to reach it Surprisingly effective..

Moving Forward

As you gain confidence with these fundamentals, explore additional security features such as SELinux or AppArmor for enhanced access controls, audit logs for tracking file access patterns, and automated permission management through configuration management tools like Ansible. These advanced topics build upon the solid foundation of traditional Unix permissions covered in this guide.

Mastering Linux file permissions is an ongoing journey that pays dividends in system security and operational reliability. By implementing the techniques outlined here, you are well-equipped to create secure, collaborative environments that protect sensitive data while supporting productive workflows Simple as that..