Arch Linux Security Hardening Guide: Manual Implementation

Peter Kriel
Sep 26, 2025
7 min read

Updated: Sep 27, 2025

Arch Security

This guide details the manual steps to implement Kicksecure-inspired security features on Arch Linux. All commands requiring root privileges are prefixed with sudo.

I. Preparation and Core System Installations

These packages provide the foundational layers for system protection, application isolation, and kernel security.

Security Feature Explanations and Risks

Feature	Description	Potential Risk (Not Installing)	Potential Risk (Installing)
Linux-Hardened Kernel	A drop-in replacement kernel that includes multiple security-focused features like process namespace separation, memory restrictions, and other mitigations to minimize the attack surface.	Higher exposure to kernel-level exploits and privilege escalation attacks.	Slight, usually negligible, decrease in performance; extremely rare potential for hardware/driver compatibility issues.
Timeshift	A system restoration utility that creates incremental snapshots of your filesystem (e.g., your root partition). It is your essential rollback tool.	Inability to easily and quickly recover from system-breaking updates or configuration errors.	Uses significant disk space to store snapshots, requiring proper configuration to manage space.
Firejail	A SUID program that utilizes Linux Namespaces and seccomp-bpf to confine applications in a secure sandbox, isolating them from the rest of the system.	A compromised application (like a web browser) could gain unauthorized access to your home directory or other system files.	May break the functionality of applications that require specific, un-sandboxed access to system resources or other programs.
UFW (Uncomplicated Firewall)	An easy-to-use frontend for Linux's iptables and nftables that simplifies rule management. Essential for controlling network access.	System ports are exposed to the network, significantly increasing the attack surface to remote attacks and unauthorized connections.	If misconfigured, can block essential services (like SSH, HTTP) and lock you out of your system.

Manual Installation and Setup Commands

Install Packages:

Bash

# Update the system and install the required packages

sudo pacman -Syu sudo pacman -S timeshift firejail ufw apparmor linux-hardened linux-hardened-headers

Enable and Configure Firewall (UFW):

For a desktop/client machine, the recommended policy is to deny incoming connections and allow outgoing connections.

Bash

# 1. Set default policies: Deny incoming, Allow outgoing sudo ufw default deny incoming sudo ufw default allow outgoing # 2. Add exceptions for services you need (e.g., SSH, if you connect remotely) # sudo ufw allow ssh # 3. Enable UFW and set it to start on boot sudo systemctl enable --now ufw # 4. Check the status sudo ufw status verbose

II. Privilege Separation and Account Hardening

These steps restrict user privileges and apply stricter authentication controls to prevent brute-force attacks.

Security Feature Explanations and Risks

Feature	Description	Potential Risk (Not Implementing)	Potential Risk (Implementing)
Umask 077/027	Sets the default permissions for newly created files/directories. 077 restricts access to the owner only. 027 allows read/execute access to the group, but restricts all other users.	Files are created with permissive defaults (022), potentially allowing other local users to read your private data.	In multi-user environments, this can require users to manually adjust permissions (chmod) if they need to share files.
PAM Faillock	Configures Pluggable Authentication Modules (PAM) to automatically lock a user account after a specific number of failed login attempts. This mitigates brute-force attacks.	Brute-force attacks on passwords can continue indefinitely until a successful login is achieved.	A Denial-of-Service (DoS) attack could intentionally lock out legitimate users (or even the root account if configured with even_deny_root).

Manual Hardening Commands

Set Umask to 077 (System-Wide): This enforces the strictest file permissions by default (owner-only access).
Bash
# Create a new configuration file to set the umask

sudo nano /etc/profile.d/set_umask.sh

Add the following line to the file and save:

Bash

# Set the system-wide umask for owner-only file access umask 077

Configure PAM Faillock: This requires editing two core PAM configuration files to add the pam_faillock.so module.
- Configuration Parameters:
  - deny=3: Lock the account after 3 consecutive failures.
  - fail_interval=900: Failures must occur within 900 seconds (15 minutes).
  - unlock_time=600: Unlock the account after 600 seconds (10 minutes).
  - even_deny_root: Applies the lockout policy to the root account as well.
A. Edit /etc/pam.d/system-auth: Add the following lines before the first auth and account sections, respectively:

Plaintext
# Before the first 'auth' line: auth required pam_faillock.so preauth audit deny=3 even_deny_root fail_interval=900 unlock_time=600 # Before the first 'account' line: account required pam_faillock.so

B. Edit /etc/pam.d/password-auth: Add the following line after the last password section:
Plaintext
# After the last 'password' line: password optional pam_faillock.so

III. Kernel and Low-Level Hardening

These steps lock down the kernel's behavior to prevent common exploit chains and enable Mandatory Access Control (MAC).

Security Feature Explanations and Risks

Feature	Description	Potential Risk (Not Implementing)	Potential Risk (Implementing)
Sysctl Hardening	Modifying kernel run-time parameters (Sysctl variables) to disable insecure functions, restrict information disclosure, and improve network resilience against DoS attacks.	Kernel parameters remain at default settings, increasing vulnerability to network enumeration, DoS attacks, and information leaks.	Incorrect settings can lead to performance issues or unintended network behavior (e.g., aggressive reverse path filtering blocking legitimate traffic).
AppArmor	A Mandatory Access Control (MAC) system that limits the capabilities of programs (e.g., which files they can access) using security profiles. It confines misbehaving or compromised processes.	Compromised applications can operate with full user privileges.	A poorly written or missing AppArmor profile can prevent a legitimate application from working, potentially requiring manual profile creation or tuning.
LKRG (Linux Kernel Runtime Guard)	A Loadable Kernel Module (LKM) designed to detect and prevent exploitation of the Linux kernel itself. It acts as a last line of defense against kernel-level rootkits and exploits.	Direct kernel memory manipulation attacks and kernel-level rootkits have a higher chance of success.	Introduces a measurable, but small, performance overhead and carries a minimal risk of system instability if a genuine integrity violation is detected.

Manual Hardening Commands

Sysctl Hardening: Create a dedicated configuration file for security parameters.

Bash

sudo nano /etc/sysctl.d/99-security-hardening.conf

Add the following recommended parameters and save the file:

Code snippet
# Controls kernel.kexec_load_disabled = 1 kernel.dmesg_restrict = 1 kernel.kptr_restrict = 2 kernel.yama.ptrace_scope = 2 fs.protected_hardlinks = 1 fs.protected_symlinks = 1 kernel.unprivileged_userns_clone = 0 # Networking net.ipv4.ip_forward = 0 net.ipv6.conf.all.forwarding = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_timestamps = 0 net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.log_martians = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1
Apply the changes immediately (they will also be loaded at boot):

Bash

sudo sysctl -p /etc/sysctl.d/99-security-hardening.conf
LKRG (Linux Kernel Runtime Guard) Installation (AUR): LKRG is in the Arch User Repository (AUR), so an AUR helper like yay is required.
- A. Install yay (if necessary):
  Bash
  # Install build tools sudo pacman -S --needed git base-devel # Download, build, and install yay git clone https://aur.archlinux.org/yay.git cd yay makepkg -si cd .. rm -rf yay
- B. Install lkrg-dkms: The DKMS version ensures the module is automatically rebuilt for new kernels.
  Bash
  yay -S lkrg-dkms # Enable the LKRG systemd service to ensure it loads at boot sudo systemctl enable --now lkrg.service
Configure Kernel Parameters in Bootloader: These parameters must be passed to the kernel at boot time to enable AppArmor and other security modules.
- Required parameters:
  - lsm=landlock,lockdown,yama,integrity,apparmor,bpf: Sets the order of Linux Security Modules (LSMs). AppArmor must be included.
  - security=apparmor: Explicitly tells the kernel to use AppArmor as the default MAC.
  - random.trust_cpu=on: Improves the quality of the kernel's entropy pool.
If using GRUB (most common):
1. Edit /etc/default/grub.
2. Locate the line GRUB_CMDLINE_LINUX_DEFAULT= and add the parameters inside the quotes.
  Example:
  Plaintext
  GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet random.trust_cpu=on security=apparmor lsm=landlock,lockdown,yama,integrity,apparmor,bpf"
3. Regenerate the GRUB configuration file:
  Bash
  sudo grub-mkconfig -o /boot/grub/grub.cfg
If using systemd-boot:
1. Edit the entry file for your kernel, located in /boot/loader/entries/.
2. Add the parameters to the options line within that file.
AppArmor Service: Ensure the userspace daemon is running to load and enforce security profiles.
Bash
# Enable and start the AppArmor service sudo systemctl enable --now apparmor.service # Verify AppArmor is enabled aa-enabled

Final Step: Reboot

A system reboot is mandatory for the Linux-Hardened Kernel, Kernel Parameters, and LKRG to take effect.

Bash

sudo reboot

If you want to run the other two scripts again do it like this

check-update.sh

./check-update.sh setup //to setup everything

./check-update.sh //to test it

hardenclamav.sh

sudo ./hardenclamav.sh //installs everything normally

apparmor-clamav-warnings.sh

sudo apparmor-clamav-warnings.sh setup //to setup everything

sudo apparmor-clamav-warnings.sh //to test it

Troubleshooting Solutions

Here are solutions for common issues you might encounter when running your Arch Linux security scripts.

1. check-update.sh Troubleshooting: Manual libnotify Installation

The check-update.sh script relies on libnotify to work with dunst for desktop notifications. If the script fails to install this dependency, you can install it manually.

Problem: Notifications are not appearing, and the script failed to install dependencies. Solution: Manually install the libnotify and dunst packages.

Command:

Bash

sudo pacman -S --noconfirm libnotify dunst

2. hardenclamav.sh Troubleshooting: Restarting clamd@scan.service

The ClamAV on-access scanning feature (clamonacc) is critical for real-time protection. The hardenclamav.sh script should enable and start the service, but if it fails, you can manage it manually using systemctl. The script uses the clamd@scan.service template for this.

Problem: Real-time scanning is not active after running hardenclamav.sh. Solution: Manually enable and start the clamd@scan.service.

Commands:

Bash

# 1. Enable the service to ensure it starts on boot
sudo systemctl enable clamd@scan.service

# 2. Start the service immediately
sudo systemctl start clamd@scan.service

# 3. Check the status to confirm it's running
sudo systemctl status clamd@scan.service

3. apparmor-clamav-warnings.sh Troubleshooting: Testing ClamAV Real-Time Scanning

The best way to confirm that your clamonacc service (started by hardenclamav.sh) and your monitoring script (apparmor-clamav-warnings.sh) are working is to use the EICAR test file. This is a non-viral file universally detected by antivirus programs to safely test functionality.

The apparmor-clamav-warnings.sh script mentions using the EICAR string and specifies the path as EICAR_PATH="/home/$USER/script/eicar_test.txt".

Problem: Need to confirm real-time scanning is active and the warning script works. Solution: Create the EICAR test file in a monitored location and check the results.

Steps and Commands:

Create the Test Directory: Ensure the script directory exists in your home directory (the user defined in the script).
Bash
mkdir -p ~/script
Create the EICAR Test File: Write the official EICAR test string into a file using the path defined in your script:
Bash
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > ~/script/eicar_test.txt
If ClamAV's on-access scanner (clamonacc) is working, it should immediately detect and quarantine/delete this file upon its creation.
Check for Detection: If the file is deleted immediately, real-time scanning is working. If not, wait a moment and then check the ClamAV log file defined in your script (/var/log/clamav/clamd.log):
Bash
sudo grep 'EICAR-Test-File' /var/log/clamav/clamd.log
You should see an entry indicating the file was detected and, ideally, moved or removed.
Run the Warning Script: Manually run the apparmor-clamav-warnings.sh script with sudo. Since a detection should be recorded in the log, the script should read it and fire a desktop notification (if dunst is running).
Bash
sudo ./apparmor-clamav-warnings.sh