Simulation Lab 13.1: Module 13 Using Discretionary Access Control

The cornerstone of secure operating systems lies in the ability to control access to resources, ensuring that data is protected from unauthorized modification or disclosure. Discretionary Access Control (DAC) stands as a fundamental security model, placing access control decisions in the hands of resource owners. This flexibility allows for granular control, but also introduces potential vulnerabilities if not properly managed. This article explores Simulation Lab 13.1: Module 13, focusing on how DAC is implemented and its implications for system security.

Understanding Discretionary Access Control (DAC)

DAC operates on the principle that the owner of a resource (a file, a directory, or even a process) has the authority to determine who can access it and what actions they are permitted to perform. This contrasts with other access control models, such as Mandatory Access Control (MAC), where the system dictates access based on pre-defined security policies.

Key Characteristics of DAC:

Ownership: Every resource has an owner, typically the user who created it.
Permissions: Owners assign permissions to other users or groups, specifying the type of access allowed (read, write, execute).
Flexibility: DAC provides a high degree of flexibility, allowing users to customize access control to suit their specific needs.
Vulnerability: The flexibility of DAC can also be its weakness. If users are not careful in assigning permissions, they can inadvertently grant unauthorized access to sensitive data.

Simulation Lab 13.1: Module 13 - A Hands-On Approach

Simulation Lab 13.1: Module 13 provides a practical environment for understanding and implementing DAC. The lab typically involves scenarios where users need to configure permissions on files and directories, manage user accounts and groups, and analyze the impact of DAC decisions on system security.

Typical Lab Activities:

Creating Users and Groups: The lab often begins with creating user accounts and groups. This allows students to understand how DAC can be applied to individual users or to groups of users, simplifying access management.
Setting File and Directory Permissions: A core activity involves setting permissions on files and directories. Students learn to use commands (e.g., chmod in Linux/Unix) to grant or revoke read, write, and execute permissions to different users or groups.
Analyzing Access Control Lists (ACLs): Some labs may introduce ACLs, which provide a more granular way to manage permissions. ACLs allow specifying permissions for individual users or groups, even if they are not the owner of the resource.
Testing Access Control: After configuring permissions, students test whether the intended access control is enforced. This involves logging in as different users and attempting to access or modify files and directories.
Identifying Vulnerabilities: The lab may present scenarios where poorly configured DAC settings lead to security vulnerabilities. Students need to analyze the situation and identify how to mitigate the risks.

Step-by-Step Guide to Implementing DAC in a Simulated Environment

Let's outline a general approach to implementing DAC within a simulated environment, similar to what you might encounter in Simulation Lab 13.1: Module 13. This example will be geared towards a Linux/Unix-like environment, as it's a common platform for learning about DAC.

Step 1: User and Group Management

Creating Users: Use the useradd command to create new user accounts. For example:
```
sudo useradd alice
sudo useradd bob
```
Remember to set passwords for these users using the passwd command:
```
sudo passwd alice
sudo passwd bob
```
Creating Groups: Use the groupadd command to create new groups. For example:
```
sudo groupadd developers
sudo groupadd testers
```
Adding Users to Groups: Use the usermod command to add users to groups. For example:
```
sudo usermod -a -G developers alice
sudo usermod -a -G testers bob
```
The -a option ensures that the user is added to the new group without being removed from their existing groups. The -G option specifies the group to add the user to.

Step 2: Creating Files and Directories

Creating a Directory: Use the mkdir command to create a new directory. For example:
```
mkdir /home/alice/project
```
Creating a File: Use the touch command to create a new file. For example:
```
touch /home/alice/project/document.txt
```

Step 3: Setting Permissions Using chmod

The chmod command is the primary tool for setting permissions in DAC. It uses a symbolic or numeric representation of permissions.

Understanding Permission Symbols:
- r: Read permission
- w: Write permission
- x: Execute permission
Understanding User Categories:
- u: User (owner)
- g: Group
- o: Others (everyone else)
- a: All (user, group, and others)
Setting Permissions using Symbolic Mode: For example, to give the owner read, write, and execute permissions, the group read and execute permissions, and others only read permission:
```
chmod u=rwx,g=rx,o=r /home/alice/project/document.txt
```
Adding Permissions: Use the + symbol to add permissions. For example, to add write permission to the group:
```
chmod g+w /home/alice/project/document.txt
```
Removing Permissions: Use the - symbol to remove permissions. For example, to remove write permission from others:
```
chmod o-w /home/alice/project/document.txt
```
Setting Permissions using Numeric Mode: Numeric mode uses a three-digit number to represent permissions for the user, group, and others. Each digit is a sum of the following values:
- 4: Read permission
- 2: Write permission
- 1: Execute permission
For example, 755 represents:
- User: 4 + 2 + 1 = 7 (read, write, execute)
- Group: 4 + 1 = 5 (read, execute)
- Others: 4 + 1 = 5 (read, execute)
To set the same permissions as in the symbolic example above, use:
```
chmod 755 /home/alice/project/document.txt
```

Step 4: Changing Ownership Using chown

The chown command is used to change the owner and group of a file or directory.

Changing the Owner: To change the owner of a file to bob:
```
sudo chown bob /home/alice/project/document.txt
```
Changing the Group: To change the group of a file to testers:
```
sudo chown :testers /home/alice/project/document.txt
```
Changing Both Owner and Group: To change both the owner and group:
```
sudo chown bob:testers /home/alice/project/document.txt
```

Step 5: Using Access Control Lists (ACLs) with setfacl and getfacl

ACLs provide more fine-grained control than standard permissions.

Setting ACLs with setfacl:
- To grant read and write permissions to user bob on a file:
```
setfacl -m u:bob:rw /home/alice/project/document.txt
```
- To grant read and execute permissions to the testers group on a directory:
```
setfacl -m g:testers:rx /home/alice/project
```
- To set a default ACL on a directory, which will apply to all new files and subdirectories created within it:
```
setfacl -d -m u:bob:rw /home/alice/project
```
Viewing ACLs with getfacl:

To view the ACLs on a file or directory:
```
getfacl /home/alice/project/document.txt
```

Step 6: Testing and Verification

After setting permissions, it's crucial to test and verify that they are working as intended.

Log in as different users: Use the su command or a separate terminal to log in as different users (e.g., alice, bob).
Attempt to access files and directories: Try to read, write, or execute files and directories based on the permissions you've set.
Verify the results: Check whether the access is allowed or denied as expected.

Example Scenario:

Imagine you have a project directory /home/alice/project owned by user alice. You want to:

Allow members of the developers group to read and write files in the directory.
Allow members of the testers group to only read files in the directory.
Prevent all other users from accessing the directory.

Here's how you might configure DAC:

Set the group ownership of the directory to developers:
```
sudo chown alice:developers /home/alice/project
```
Set the permissions of the directory:
```
chmod 770 /home/alice/project
```
This sets the following permissions:
- Owner (alice): Read, write, and execute (7)
- Group (developers): Read, write, and execute (7)
- Others: No permissions (0)
Use ACLs to allow testers to read:
```
setfacl -m g:testers:r-x /home/alice/project
```
This grants read and execute permissions to the testers group, but not write permissions. The execute permission is needed to traverse into the directory.

By following these steps, you can effectively implement DAC in a simulated environment and gain a better understanding of how it works. Remember to always test and verify your configurations to ensure that they are working as intended and that your system is secure.

Common DAC Vulnerabilities and Mitigation Strategies

While DAC offers flexibility, it is also susceptible to several vulnerabilities if not implemented carefully. Understanding these vulnerabilities is crucial for creating a secure system.

1. Privilege Escalation:

Vulnerability: A user with limited privileges might be able to exploit a misconfigured file or program with excessive permissions to gain higher privileges. For example, a program owned by root with the setuid bit set could allow a normal user to execute code with root privileges.
Mitigation:
- Principle of Least Privilege: Grant users only the minimum permissions necessary to perform their tasks.
- Regular Audits: Periodically review file and directory permissions to identify and correct any misconfigurations.
- Disable Setuid/Setgid: Avoid using the setuid and setgid bits unless absolutely necessary. If they are required, ensure that the programs using them are thoroughly audited for security vulnerabilities.

2. Trojan Horses:

Vulnerability: A malicious user could create a program that appears to be legitimate but performs malicious actions when executed. If a user with high privileges executes the Trojan horse, the malicious actions will be performed with those privileges.
Mitigation:
- User Education: Educate users about the risks of executing untrusted programs and downloading files from unknown sources.
- Antivirus Software: Use antivirus software to detect and remove known malware.
- Code Signing: Use code signing to verify the authenticity and integrity of software.

3. Insecure File Permissions:

Vulnerability: Leaving files with overly permissive permissions (e.g., world-writable) can allow unauthorized users to modify or delete sensitive data.
Mitigation:
- Restrictive Permissions: Set file permissions to the most restrictive level possible while still allowing authorized users to perform their tasks.
- Regular Audits: Regularly audit file and directory permissions to identify and correct any overly permissive settings.
- Default Permissions: Configure default permissions for new files and directories to be secure.

4. Symlink Attacks:

Vulnerability: A symbolic link (symlink) can be used to redirect access to a different file or directory. An attacker could create a symlink to a sensitive file and then trick a privileged program into accessing it.
Mitigation:
- Limit Symlink Creation: Restrict the ability to create symlinks to trusted users.
- Safe File Handling: Ensure that programs properly validate file paths and do not blindly follow symlinks.
- fs.protected_symlinks and fs.protected_hardlinks sysctl settings: These settings, if available on your system, can help mitigate symlink and hardlink attacks.

5. Race Conditions:

Vulnerability: A race condition occurs when the outcome of a program depends on the unpredictable timing of events. An attacker could exploit a race condition to modify a file between the time it is checked for permissions and the time it is accessed.
Mitigation:
- Atomic Operations: Use atomic operations to perform multiple actions as a single, indivisible unit.
- File Locking: Use file locking mechanisms to prevent concurrent access to files.
- Careful Programming: Write code that is robust against race conditions.

6. Reliance on User Discretion:

Vulnerability: The core weakness of DAC is its reliance on users to make informed and secure decisions about access control. Users may be careless, ignorant, or even malicious, leading to vulnerabilities.
Mitigation:
- User Education: Provide users with training on security best practices and the importance of secure access control.
- Regular Audits: Regularly audit file and directory permissions to identify and correct any misconfigurations.
- Consider MAC: In situations where security is paramount, consider using a more restrictive access control model such as Mandatory Access Control (MAC).

By understanding these vulnerabilities and implementing appropriate mitigation strategies, you can significantly improve the security of a system using DAC.

The Broader Context: DAC vs. MAC and RBAC

DAC is just one of several access control models. It's important to understand how it compares to other models, such as Mandatory Access Control (MAC) and Role-Based Access Control (RBAC).

Discretionary Access Control (DAC):

Control: Access control decisions are made by the owner of the resource.
Flexibility: High degree of flexibility.
Security: Can be vulnerable to misconfiguration and malicious users.
Implementation: Relatively simple to implement.

Mandatory Access Control (MAC):

Control: Access control decisions are made by the system based on pre-defined security policies.
Flexibility: Limited flexibility.
Security: More secure than DAC, as users cannot override security policies.
Implementation: More complex to implement.
Examples: SELinux, AppArmor.

Role-Based Access Control (RBAC):

Control: Access control decisions are based on the roles that users are assigned.
Flexibility: Moderate flexibility.
Security: More secure than DAC, as access is based on roles rather than individual users.
Implementation: More complex than DAC, but simpler than MAC.
Examples: Active Directory, many enterprise applications.

Choosing the Right Model:

The choice of access control model depends on the specific security requirements of the system.

DAC: Suitable for systems where flexibility is important and the risk of misconfiguration is low.
MAC: Suitable for systems where security is paramount and flexibility is less important.
RBAC: Suitable for systems where access control needs to be managed based on roles within an organization.

In some cases, a combination of access control models may be used to achieve the desired level of security and flexibility. For example, a system might use RBAC for managing access to applications and DAC for managing access to individual files within those applications.

Conclusion

Simulation Lab 13.1: Module 13 provides a valuable hands-on experience with Discretionary Access Control. By working through the lab activities, students gain a practical understanding of how DAC works, its strengths and weaknesses, and how to implement it effectively. Understanding DAC is a fundamental skill for anyone involved in system administration, security, or software development. While DAC offers flexibility and ease of implementation, it's crucial to be aware of its vulnerabilities and to implement appropriate mitigation strategies. By combining a solid understanding of DAC with other access control models and security best practices, you can build more secure and resilient systems.