Week-3: Access Control

Lab setup: if you're still not familer with the lab setup please re-visit Week1's lab (can be find in the module folder or here(if you have NET access)):

All our labs should be in one folder, which you can find in the public drive under the module name CSF-MSc-19133.
To install a VM, you can double-click on the VM (choose csf_vm1) for this week, which is located in the VM folder within the module folder.

If VirtualBox encounters the error E_invalidarg (0x80070057), please follow these steps in lab week-1 can be found in the same moudle folder under week-1 or if you have connection you can find it here within the Pre-requisites

Log in to Kali Linux:
- Username: csf_vm1
- Password: kalivm1 (or the one you configured if you have done so).
Open Terminal:
- Once logged in, open the Terminal application by clicking on the Terminal icon in the taskbar or by pressing Ctrl + Alt + T.

Part 1: Permissions and ownerships

Task 1: Create a Folder and Three Files

Navigate to the Home Directory:

In the terminal, ensure you are in the home directory by typing:

cd

you can ensure that you're there by using the cmd pwd, and the output should be `home/csf_vm1/

Create a Folder:

To create a new folder called AccessControlLab, run the following command:

mkdir AccessControlLab

Navigate into the Folder:

Move into the newly created folder:

cd AccessControlLab

Create Three Files:

Create three empty text files using the touch command:

touch file1.txt file2.txt file3.txt

Verify the Files:

List the contents of the folder to confirm the files were created:

ls

You should see the following output:

file1.txt  file2.txt  file3.txt

Task 2: Understanding File Permissions and Ownership

1. Viewing File Permissions and Ownership

In Linux, every file and directory has associated permissions and ownership, which control who can access or modify them. Let’s start by displaying this information for the files you created.

List Files with Detailed Information:

In the terminal, while inside the AccessControlLab folder, type:

ls -l

This command will show a detailed list of the files along with their permissions, ownership, and other information. The output will look something like this:

-rw-r--r-- 1 csf_vm1 csf_vm1  0 Time file1.txt
-rw-r--r-- 1 csf_vm1 csf_vm1  0 Time file2.txt
-rw-r--r-- 1 csf_vm1 csf_vm1  0 Time file3.txt

2. Breaking Down the Output:

Here’s how to understand the output for each file:

File type and Permissions (-rw-r--r--):
- The first character (-) indicates the file type. A - means it is a regular file, whereas a d means it’s a directory.
- The next nine characters represent the permissions:
  - rw- → Owner permissions: Read (r), Write (w), and no Execute (-).
  - r-- → Group permissions: Read (r), no Write (-), and no Execute (-).
  - r-- → Others permissions: Read (r), no Write (-), and no Execute (-).
Number of Links (1): This refers to how many hard links point to the file.
Owner (csf_vm1): The user who owns the file.
Group (csf_vm1): The group that owns the file.
File Size (0): The size of the file in bytes.
Date and Time (current date and time): The last modification date and time.
File Name (file1.txt): The name of the file.

3. File Ownership

In Linux, each file has two types of ownership:

User (Owner): The user who created the file or was assigned ownership.
Group: A group of users who share access to files.

By default, the owner of the file is the user who created it (in this case, csf_vm1). The group associated with the file is also the user’s primary group (here, csf_vm1).

To verify the ownership of the files:

You can check it using the ls -l output, which shows the Owner and Group as the third and fourth columns respectively.

4. Changing File Permissions

To modify the permissions of a file, you can use the chmod command. For example:

Removing Write Permission for the Owner:

To remove the write permission from the owner for file1.txt, type:

chmod u-w file1.txt

Verify the change by running ls -l again. You should now see:

-r--r--r-- 1 kali kali 0 Sep 16 10:00 file1.txt

Giving Execute Permission to Others:

To allow others to execute file2.txt, type:

chmod o+x file2.txt

Verify the change with ls -l, which should show:

-rw-r--r-x 1 kali kali 0 Sep 16 10:00 file2.txt

5. Changing File Ownership

The chown command is used to change file ownership. For example:

Change the Owner of `file3.txt`:

To change the owner of file3.txt to another user (e.g., root), you need superuser privileges, so use sudo:

sudo chown root file3.txt

Verify the change:

ls -l file3.txt

The output will now show root as the owner of the file.

Change the Group of `file3.txt`:

To change the group ownership of file3.txt to sudo, use:

sudo chown :sudo file3.txt

The colon (:) separates the user and group in the chown command.

Task 3: Changing File Permissions with Numeric (Octal) Notation

In Linux, file permissions are represented by three groups: Owner, Group, and Others. Each permission (read, write, execute) is associated with a numerical value:

The permissions are usually displayed in this format: rwxrwxrwx where:

The first three letters represent the permissions for the Owner.
The next three are for the Group.
The last three are for Others (anyone else who has access).

Octal Value	Permission	Binary Representation	Symbolic Representation
0	No permission	000
1	Execute	001	--x
2	Write	010	-w-
3	Write & Execute	011	-wx
4	Read	100	r--
5	Read & Execute	101	r-x
6	Read & Write	110	rw-
7	Read, Write & Execute	111	rwx

Octal Notation Breakdown:

640 means:
- Owner: Read (4) + Write (2) = 6
- Group: Read (4) = 4
- Others: No permission (0)
744 means:
- Owner: Read (4) + Write (2) + Execute (1) = 7
- Group: Read (4) = 4
- Others: Read (4) = 4

Changing Permissions to 640

Let’s apply the 640 permission to file1.txt:

Set Permissions:

In the terminal, type the following command to set file1.txt to have 640 permissions:

chmod 640 file1.txt

Verify the Change:

Run ls -l to see the new permissions:

ls -l file1.txt

You should see:

-rw-r-- 1 kali kali 0 Sep 16 10:00 file1.txt

Explanation:

Owner: rw- → Read and Write (6).
Group: r-- → Read-only (4).
Others: `` → No permissions (0).

This means that only the owner can read and write the file, the group can only read it, and others have no access.

Below is breakdown of the understanind permissions:

Changing Permissions to 744

Next, apply the 744 permission to file2.txt:

Set Permissions:

To set file2.txt with 744 permissions, run:

chmod 744 file2.txt

Verify the Change:

Again, list the file details using:

ls -l file2.txt

You should now see:

-rwxr--r-- 1 csf_vm1 csf_vm1 0 Time file2.txt

Explanation:

Owner: rwx → Read, Write, and Execute (7).
Group: r-- → Read-only (4).
Others: r-- → Read-only (4).

Now the owner has full permissions (read, write, and execute), while the group and others can only read the file.

Common Octal Permissions:

777: Full permission for user, group, and others (rwxrwxrwx)
755: Full permission for user, read and execute for group and others (rwxr-xr-x)
644: Read and write for user, read-only for group and others (rw-r--r--)
600: Read and write for user, no permissions for group and others (rw-)

Research Questions:

What are the security implications of incorrectly setting file permissions in a multi-user environment? Provide a real-world example of a breach due to incorrect file permissions.
When would it be more secure to use chmod 640 rather than chmod 744 for sensitive files?

Part-2: Implementing Role-Based Access Control (RBAC)

Task 1: Create User Roles Using Groups

In Role-Based Access Control (RBAC), roles are represented by groups. Let's create groups to represent different roles.

Create User Roles:

In Linux, create groups to represent different roles. For example, create two roles (groups) jedi and sith:

Note: when using sudo (It's a Linux command that allows users to run commands with elevated privileges, such as the root user's privileges), the system will ask you for password, please do entry your password to confim that your're the admin user. Noramlly it asks you once per session.

If you're using csf_vm1, the password is kalivm1

If you're using csf_vm2, the password is kalivm2

sudo groupadd jedi
sudo groupadd sith

Verify Group Creation:

Use the following command to check if the groups were created successfully:

cat /etc/group

You should see the groups jedi and sith in the list (at end of the list).

Task 2: Create Users and Assign Them to Roles (Groups)

Now, we will create users and assign them to the roles (groups) we created.

Note: in Linux, -h tag is used for help (command -h) or human-readable output (e.g., ls -lh, useradd -h).

Create Users:

Create two users, luke and vader, using the following commands:

sudo useradd -m luke
sudo useradd -m vader

Verify users Creation:

Use the following command to check if the users were created successfully:

cat /etc/passwd

You should see the groups jedi and sith in the list (at end of the list).

or use the follwing to view them easily

getent passwd | cut -d: -f1

Assign Passwords to These Users:

Entry password(s) of you choose. To make it simple entry the password for the vm that you're using atm which is kalivm1.
```
  sudo passwd luke
```
```
sudo passwd vader
```

Assign Users to Groups (Roles):

Add luke to the jedi group:

sudo usermod -aG jedi luke

Add vader to the sith group:

sudo usermod -aG sith vader

Verify Group Membership:

Check the groups of each user to ensure they are assigned correctly:

groups luke
groups vader

You should see luke as part of jedi and vader as part of sith.

Task 3: Create Directories for Role-Based Access

Next, let's create directories that will only be accessible by specific roles (groups).

Create Directories for Each Role:

In the home directory, create two directories: one for jedi and one for sith:

sudo mkdir /home/jedi
sudo mkdir /home/sith

Assign Ownership of Directories to the Respective Roles:

Change the ownership of the jedi directory to the jedi group:

sudo chown :jedi /home/jedi

Change the ownership of the sith directory to the sith group:

sudo chown :sith /home/sith

Set Permissions for the Directories:

Set the permissions so that only the respective groups have access to these directories:

For jedi (read, write, and execute for the jedi group only):

sudo chmod 770 /home/jedi

For sith (read, write, and execute for the sith group only):

sudo chmod 770 /home/sith

Verify Permissions:

Run ls -l to verify that the permissions are set correctly:

ls -ld /home/jedi /home/sith

The output should show the following:

drwxrwx 2 root jedi 4096 Sep 16 10:00 /home/jedi
drwxrwx 2 root sith 4096 Sep 16 10:00 /home/sith

Explanation:

The jedi group has full access (read, write, execute) to jedi.
The sith group has full access (read, write, execute) to sith.

Task 4: Test Access Control

Now, let’s switch users and verify that they can access only the directories assigned to their roles.

Switch to the user luke:

su - luke

Try accessing the jedi:

cd /home/jedi

Result: Luke (as a Jedi) should have access to the jedi. You can test it by using pwd cmd and the outcome should be /home/jedi and not luke.

Try accessing the sith:

cd /home/sith

Result: Luke should not have access to the sith directory and should see a permission denied error.

Switch to the user vader:

su - vader

Try accessing the sith:

cd /home/sith

Result: Vader (as a Sith) should have access to the sith directory.

Try accessing the jedi:

cd /home/jedi

Result: Vader should not have access to the jedi directory and should see a permission denied error.

Part 3: PAM

Overview of PAM Configuration

PAM is configured via files located in /etc/pam.d/. Each service that uses PAM for authentication (like login, sshd, sudo, etc.) has its own configuration file in this directory.

PAM Configuration Files:

The main directory for PAM configurations is /etc/pam.d/.
Each file in this directory corresponds to a service (e.g., login, sshd, sudo, etc.) that uses PAM for authentication.

To view the contents of this directory:

ls /etc/pam.d/

You should see files like common-auth, login, sshd, sudo, etc.

This file is used for authentication configuration. It defines how users are authenticated on the system. For example, it could dictate whether passwords, biometric methods, or other mechanisms are used for login. PAM modules listed in this file decide how authentication is performed across various services (such as login, sudo, etc.).

Example use: When logging in through the terminal or a graphical login manager, this file is consulted to verify if the user provided the correct credentials.

2. `common-password`

This configuration is responsible for password management. It defines the rules for password changes, including whether passwords must be strong or whether password history should be checked to avoid reuse of old passwords.

Example use: When a user changes their password using the passwd command, the rules defined in this file ensure that the password meets system policies.

3. `common-session`

This file manages session-related tasks after authentication. It often includes session cleanup and initialization tasks, such as mounting user directories or logging user sessions. It’s executed after the user is successfully authenticated but before they gain access to a session.

and more

Task 1: Basic PAM Configuration for Authentication

We will start by modifying PAM to enhance security using a simple password policy for the system’s login service.

Back Up PAM Configuration:

It’s always good practice to back up the current PAM configuration files before making any changes.
Create a backup of the common-auth and login files:

sudo cp /etc/pam.d/common-auth /etc/pam.d/common-auth.bak

This command copies the common-auth file to a backup file named common-auth.bak. The sudo command is used because modifying system files typically requires administrative privileges.

sudo cp /etc/pam.d/login /etc/pam.d/login.bak

Similarly, this command copies the login file to a backup file named login.bak. The backup ensures that if any changes are made to the original login file, you can revert back to the previous configuration using the backup.

Understanding the `common-auth` File:

The /etc/pam.d/common-auth file handles authentication for all PAM-enabled services.
View the contents of common-auth:

cat /etc/pam.d/common-auth

You will see lines like:

auth    required    pam_unix.so

This means that the PAM auth phase uses the pam_unix.so module to authenticate users via standard Unix password-based authentication.
Please go skim through it.

List of PAM modules for FYI

PAM Module	Description
`pam_unix.so`	Provides traditional UNIX authentication (e.g., checking passwords against `/etc/passwd` or `/etc/shadow`).
`pam_deny.so`	Always denies access, often used as a safety measure at the end of configuration files.
`pam_permit.so`	Always allows access. It is sometimes used as a placeholder or to simplify testing.
`pam_tally2.so`	Keeps track of login attempts and can lock out users after a specific number of failures.
`pam_env.so`	Sets and unsets environment variables based on configuration files.
`pam_faildelay.so`	Introduces a delay on authentication failure to slow down brute-force attacks.
`pam_limits.so`	Enforces resource limits, such as file size, CPU usage, or number of processes per user.
`pam_motd.so`	Displays the message of the day (MOTD) upon login.
`pam_nologin.so`	Prevents non-root users from logging in when the `/etc/nologin` file exists.
`pam_rootok.so`	Bypasses authentication if the user is root (UID 0).
`pam_securetty.so`	Restricts root logins to terminals listed in the `/etc/securetty` file.
`pam_succeed_if.so`	Allows or denies access based on specific user attributes, such as group membership.
`pam_tty_audit.so`	Enables or disables TTY auditing for the specified users.
`pam_userdb.so`	Allows user authentication based on a custom Berkeley DB.
`pam_wheel.so`	Restricts the use of `su` to users in the `wheel` group.
`pam_cracklib.so`	Enforces password strength policies by checking password quality.
`pam_pwhistory.so`	Prevents users from reusing old passwords by keeping a history of previous passwords.
`pam_exec.so`	Executes an external command and acts based on the return value of the command.
`pam_ldap.so`	Allows authentication using an LDAP directory.
`pam_radius.so`	Allows authentication using a RADIUS server.
`pam_google_authenticator.so`	Integrates Google Authenticator for two-factor authentication.
`pam_systemd.so`	Initializes systemd user sessions for processes like managing user logins and sessions.

Task 2: Implementing Password Complexity Rules

You can enforce password complexity by using the pam_pwquality module, which enforces password policies such as minimum length and character variety.

Open the `common-password` File:

This file is used to manage password requirements. Open it using a text editor:

sudo nano /etc/pam.d/common-password

Add a Password Policy Using `pam_pwquality`:

Find the line that uses pam_unix.so and add the pam_pwquality.so line before the pam_unix.so line in your file. This ensures that the password quality is checked before the standard password processing.

The new line should look something like this:

password required pam_pwquality.so retry=3 minlen=12 difok=3 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1

Explanation:

retry=3: Allows 3 attempts before the user is locked out.
minlen=12: Requires a minimum password length of 12 characters.
difok=3: Ensures at least 3 different character types.
ucredit=-1: Requires at least one uppercase letter.
lcredit=-1: Requires at least one lowercase letter.
dcredit=-1: Requires at least one digit.
ocredit=-1: Requires at least one special character.

Save the Changes:

Press Ctrl + X to exit, then Y to confirm the save, and hit Enter.

In PAM, control flags determine how authentication failures are handled. The table below compares two commonly used control flags: requisite and required.

Control Flag	Behavior on Failure	Modules Processed After Failure?	Use Case
`requisite`	Immediate failure	No	Stop further processing upon failure.
`required`	Failure is recorded	Yes	Continue processing to the next one, but authentication fails if any `required` module fails.

Next, we’ll configure PAM to lock a user account after a certain number of failed login attempts using the pam_tally2 or pam_faillock module, depending on the Linux distribution.

For `pam_tally2`:

Modify the `common-auth` File:

Add the following line to /etc/pam.d/common-auth to enable the account lockout policy:

auth required pam_tally2.so deny=5 unlock_time=120 onerr=fail audit

Explanation:

deny=5: Locks the account after 5 failed login attempts.
unlock_time=120: Automatically unlocks the account after 120 seconds (2 minutes).
onerr=fail: Denies access in case of a system error.
audit: Logs each failed attempt.

Modify the `common-account` File:

Add the following line to the /etc/pam.d/common-account file:

account required pam_tally2.so

account required pam_tally2.so is necessary to ensure that failed login attempts are tracked and that account locking policies are enforced as part of the PAM authentication process. This adds an extra layer of security against unauthorized access.

For `pam_faillock` (Alternative to `pam_tally2`):

If you are using a newer Linux distribution that uses pam_faillock, edit the /etc/pam.d/login file:

sudo nano /etc/pam.d/login

Add the Following Lines:

Insert the following lines to configure pam_faillock:

auth required pam_faillock.so preauth silent deny=5 unlock_time=600
auth required pam_faillock.so authfail deny=5 unlock_time=600
account required pam_faillock.so

Explanation:

Similar parameters as pam_tally2, but using pam_faillock to enforce login attempt policies.

Task 4: Testing PAM Configuration

After configuring PAM, it’s crucial to test that the changes are working as expected.

Testing Password Complexity:

Try changing a password for a user ( pick one e.g., csf_vm1 or luke/vader) that doesn’t meet the new password policy:

passwd csf_vm1

Enter a password that is too simple (e.g., password123) and PAM should reject it due to not meeting the complexity requirements.

Testing Account Lockout:

Try logging in with incorrect credentials five times in a row to trigger the account lockout:

su spock

After five failed attempts, the account should be locked, and you will not be able to log in.

Checking the Lock Status:

Use pam_tally2 (or pam_faillock) to check the lock status of the account:

pam_tally2 --user=csf_vm1

You should see the tally of failed login attempts.

Unlocking the Account (if locked):

To manually unlock the account, use:

pam_tally2 --user=csf_vm1 --reset

MSc Cybersecurity Technology: P19133-2024/25

Lab setup: if you're still not familer with the lab setup please re-visit Week1's lab (can be find in the module folder or here(if you have NET access)):