Lab: Implementing Role-Based Access Control (RBAC) in Linux

Securing a File System with Users, Groups, and ACLs

1. Project Objective & Defined Roles

This project demonstrates the implementation of a Role-Based Access Control (RBAC) system on a Linux file system. The goal was to secure a directory structure by defining specific user roles and enforcing the principle of least privilege using standard permissions and Access Control Lists (ACLs).

Role User Access Permissions
Administrator admin_user Full access (read/write/execute) to all directories.
Staff staff_user Read/write to `/staff`, read-only to `/admin`, no access to `/guests`.
Guest guest_user Read-only access to `/guests`, no access elsewhere.

2. Configuration and Implementation Commands

Step 1: Create Directory, Users, and Groups

The initial setup involved creating the necessary directory structure, user accounts, and groups for each role.

# Create directory structure
mkdir -p /rbac-project/{admin,staff,guests}

# Create users and groups
sudo useradd -m admin_user
sudo groupadd rbac_admin
sudo usermod -aG rbac_admin admin_user

sudo useradd -m staff_user
sudo groupadd rbac_staff
sudo usermod -aG rbac_staff staff_user

sudo useradd -m guest_user
sudo groupadd rbac_guest
sudo usermod -aG rbac_guest guest_user

Step 2: Set Base and Directory-Specific Permissions

Standard Unix permissions were applied to set the primary ownership and access rights for each directory.

# Set ownership of parent directory
sudo chown -R admin_user:rbac_admin /rbac-project

# Admin directory: Full access for admin group
sudo chown admin_user:rbac_admin /rbac-project/admin
sudo chmod 750 /rbac-project/admin

# Staff directory: Full access for staff group
sudo chown admin_user:rbac_staff /rbac-project/staff
sudo chmod 770 /rbac-project/staff

# Guest directory: Read access for guest group
sudo chown admin_user:rbac_guest /rbac-project/guests
sudo chmod 750 /rbac-project/guests

Step 3: Implement Fine-Grained Control with ACLs

Access Control Lists (ACLs) were necessary to grant the `staff_user` read-only access to the `/admin` directory without changing the primary group. The SGID bit was also set to ensure new files inherit the parent directory's group.

# Create a special group for read-only access
sudo groupadd rbac_admin_readonly
sudo usermod -aG rbac_admin_readonly staff_user

# Set ACL for staff read-only access to admin directory
sudo setfacl -m g:rbac_admin_readonly:r-x /rbac-project/admin

# Set SGID bit on directories
sudo chmod g+s /rbac-project/staff
sudo chmod g+s /rbac-project/admin

3. Permission Testing and Verification

Each user role was tested to ensure the permissions were applied correctly.

# Staff User Test: Attempting to write to /admin directory
staff_user@kali:~$ touch /rbac-project/admin/staff_file.txt
touch: cannot touch '/rbac-project/admin/staff_file.txt': Permission denied

# Staff User Test: Writing to /staff directory
staff_user@kali:~$ touch /rbac-project/staff/staff_file.txt
(Success)

# Staff User Test: Attempting to access /guests directory
staff_user@kali:~$ ls -la /rbac-project/guests
ls: cannot open directory '/rbac-project/guests': Permission denied

# Guest User Test: Reading from /guests directory
guest_user@kali:~$ ls -la /rbac-project/guests
total 8
drwxr-x--- 2 admin_user rbac_guest 4096 May 6 21:15 .
... (output shows success)

# Guest User Test: Attempting to write to /guests directory
guest_user@kali:~$ touch /rbac-project/guests/guest_file.txt
touch: cannot touch '/rbac-project/guests/guest_file.txt': Permission denied

4. Observations and Lessons Learned

Key Takeaways

  • Scalability of Groups: Group-based access control is far more scalable and manageable than assigning permissions to individual users.
  • Layered Permissions: Using standard Unix permissions as a base layer and ACLs for exceptions provides a powerful, defense-in-depth approach.
  • Principle of Least Privilege: This model successfully grants each user only the minimum access necessary for their role, reducing the potential impact of a compromised account.
  • ACLs for Granularity: Standard permissions alone were insufficient. ACLs were essential for granting specific, overlapping permissions (like read-only access for one group and read-write for another).