Week 2 Session 2 Task - [Linux Hardening] Information Security Lab: Implementing DAC, MAC, and RBAC

 Hello everyone! In this post, I’d like to share my experience from a recent Information Security lab where I explored access control mechanisms in Linux. This lab focused on three critical methods that are central to Linux system security and hardening:

• DAC (Discretionary Access Control)

• MAC (Mandatory Access Control) using AppArmor

• RBAC (Role-Based Access Control) via user groups and sudo policies

What is Linux Hardening?

Linux hardening is the process of securing a Linux system by minimizing its vulnerabilities and limiting exposure to potential attacks. One of the most fundamental components of hardening is access control — determining who can access what and how.

In this task, I practiced three access control models:

1. DAC – File ownership and permissions using chmod, chown, etc.

2. MAC – Policy-based enforcement using AppArmor

3. RBAC – Role-based permission management through Linux groups and sudo rules

1. Discretionary Access Control (DAC)

Experiment 1: File Permission Basics

I started by creating a test file and inspecting its default permissions:

Typically, the owner gets rw- permissions, while others only get r--.

Experiment 2: Changing Permissions with chmod

Restricting access to the file:

Trying to read the file as a different user returned "Permission denied"

Experiment 3: Changing Ownership with chown

sudo chown user1 file1.txt

Now, user1 could access the file, and others could not.
2. Mandatory Access Control (MAC) with AppArmor
Installing and Activating AppArmor
sudo apt update
sudo apt install apparmor apparmor-utils -y
sudo systemctl enable --now apparmor

If it's already installed, we can check it using sudo aa-status:
Creating and Testing an AppArmor Profile
I wrote a simple script named test_script.sh and created a custom AppArmor policy to block its execution.
Example AppArmor Profile:
#include <tunables/global>

/tmp/praktikum_mac/test_script.sh {
    /tmp/praktikum_mac/test_script.sh ix,
    /usr/lib/x86_64-linux-gnu/** rm,
    /bin/bash rmix,
}
Load the profile with:
sudo apparmor_parser -r /etc/apparmor.d/tmp.praktikum_mac.test_script
Even if the script has execute permissions, AppArmor blocks execution based on policy.

3. Role-Based Access Control (RBAC)

Creating User Roles and Groups

sudo groupadd admin

sudo groupadd developer

sudo groupadd auditor

sudo useradd -m -G admin user1

sudo useradd -m -G developer user2

sudo useradd -m -G auditor user3

Configuring sudo Access

In /etc/sudoers.d/praktikum:

%admin ALL=(ALL) ALL

%developer ALL=(ALL) /usr/bin/git, /usr/bin/python3, /usr/bin/gcc

%auditor ALL=(ALL) NOPASSWD: /bin/cat /var/log/syslog, /bin/cat /var/log/auth.log

Role Behavior:

• Admin: Full sudo access

• Developer: Limited to development tools

• Auditor: Read-only access to system logs

Case Study: Developer vs QA Engineer

Access Table

Role	Directory	Read	Write	Execute	Notes
Developer	/var/www/html	✅	✅	✅	Full access to codebase
QA Engineer	/var/www/html	✅	❌	❌	Can only read code for review

Sudoers Policy

%developer ALL=(root) NOPASSWD: /usr/bin/chmod /var/www/html/*
%developer ALL=(root) NOPASSWD: /usr/bin/chown /var/www/html/*

%qa ALL=(root) NOPASSWD: /usr/bin/ls /var/www/html
%qa ALL=(root) NOPASSWD: /usr/bin/cat /var/www/html/*
Final Thoughts
Here’s what I learned:
DAC allows file owners to control access, but it's prone to misconfigurations.
MAC (with AppArmor) adds an extra enforcement layer beyond file permissions.
RBAC simplifies centralized access management and aligns with organizational roles
By combining DAC, MAC, and RBAC, we create a layered security model that enhances protection, minimizes unauthorized access, and improves manageability.
Key Takeaways
Always apply the principle of least privilege.
Use AppArmor or SELinux for strict execution policies.
Use RBAC for role-aligned access control in multi-user systems.
Review and audit access policies regularly.

Thanks for reading! Feel free to drop a comment if you want a copy of the AppArmor profile or sudoers file configuration.
#IDNBootCampCyber