System Documentation

⚠️ LEGAL NOTICE AND CRITICAL DISCLAIMER

This document and the associated software (Slarpx) describe a system comprising highly experimental, high-risk, and aggressive security measures.

1. NO WARRANTY: This software is provided "AS IS". Developers shall not be held responsible for any hardware failures (e.g., reduced disk lifespan due to excessive I/O load), data loss (e.g., loss of encrypted disk keys), business interruptions, or legal liabilities resulting from the use of this system.
2. INTENDED USE: Slarpx is NOT DESIGNED for end-users, corporate office workers, or gamers. This system is designed for security research and security testing.
3. MEDICAL/CRITICAL DEVICE WARNING: Do not use this operating system in life-support units, nuclear facility control systems, or air traffic control, where a failure could result in fatal consequences. The "Active Kill" (Xennytsu) mechanism it contains immediately terminates any process it detects as a threat (even if critical).

CHAPTER 1: PHILOSOPHY AND THREAT MODEL

For Slarpx, the only valid metric is Minimization of the Attack Surface.

1.1 Design Principles

• Security by Design: Security is not a patch added later; it is the foundation of the system.
• Default Deny: Everything not explicitly permitted (network ports, file access, modules) is forbidden.
• Active Hostility: The system does not remain passive against unauthorized code running on it; it detects, slows down (Poison), and destroys them (Xennytsu).

CHAPTER 2: INSTALLATION GUIDE

Installing Slarpx requires more meticulous preparation compared to standard Linux distributions.

2.1 System Requirements

• CPU: 64-bit (x86_64/amd64) processor. (Virtualization extensions are recommended).
• RAM: Minimum 4GB (8GB+ recommended as Xennytsu and Poison perform in-memory analysis).
• Storage: Minimum 32GB SSD (HDD is not recommended; I/O performance is critical).
• BIOS/UEFI: After system installation, it is recommended to enable SECURE BOOT according to Debian documentation.

2.2 Preparing Installation Media

1. Download ISO File: Obtain the .iso file from the official source.
2. Integrity Verification: Check the hash value of the downloaded file. sha256sum hardenedslarpx-1.0-amd64iso # Must match the hash published by the developer.
3. USB Writing: Write the ISO to the memory stick using the dd command. (Copy if using Ventoy, select "DD Image" mode if using Rufus). sudo dd if=slarpx.iso of=/dev/sdX bs=4M status=progress && sync

2.3 Installation Steps

1. Boot: Start the system from the USB.
2. Follow the steps of the Debian Installer
3. Disk Partitioning (CRITICAL):
   • It is recommended to select the Guided - Use entire disk and set up encrypted LVM option.
   • An unencrypted installation renders Slarpx's security architecture (especially Coldboot protection) ineffective.
   • Set a strong "Passphrase" (at least 20 characters).

2.4 First Boot After Installation (Post-Install)

1. Enter your LUKS password when the system starts.
2. Login (the default user is what you determined during installation).
3. First, check the system integrity: systemctl status xennytsu # Should be Active (running) systemctl status poison # Should be Active (running)

Hardened Slarpx is a Headless system by default and has no desktop environment. It is up to you whether to install a desktop environment or not, but for security, desktop environments using wayland are recommended, and avoid installing desktop environments termed as bloat.

Labwc is a secure desktop environment compatible with Hardened Slarpx. Its attack surface is low and it runs over the wayland protocol.

About Driver & Kernel Patches: Do not install Nvidia proprietary drivers in Hardened Slarpx; it will likely fail. Also, do not install kernel patches. Hardened Slarpx strictly restricts compilation. This measure is taken to prevent the compilation of exploits.

CHAPTER 3: KERNEL HARDENING ANALYSIS

configurations under /etc/sysctl.conf and /etc/modprobe.d/.

3.1 In-depth Analysis of Sysctl Parameters

3.1.1 Kernel Self-Protection (KSP)

• kernel.kexec_load_disabled = 1
  Technical Detail: Disables the kexec system call.
  Security Impact: Prevents a root user from loading their own manipulated kernel into memory during a reboot. This is the strongest defense against "Bootkit" and persistence attacks.
• kernel.yama.ptrace_scope = 3
  Technical Detail: Sets the Ptrace (Process Trace) capability in the Linux Kernel to its most restrictive mode.
  Security Impact: Debugging operations are completely forbidden. One process cannot read the memory of another (RWX/Read-Write-Execute memory injection is prevented). GDB and Strace will not work. It makes it impossible for malware to perform process injection.
• kernel.unprivileged_bpf_disabled = 1
  Technical Detail: Prevents unprivileged users from loading eBPF (extended Berkeley Packet Filter) bytecode.
  Security Impact: Closes BPF vulnerabilities (including Spectre variants), which are the most popular kernel exploit vectors of recent years.

3.1.2 Memory and Address Space Protections

• kernel.kptr_restrict = 2
  Effect: Hides (zeroes out) kernel memory addresses within files like /proc/kallsyms. Prevents an attacker from finding the "offset" values needed for writing kernel exploits (KASLR Bypass mitigation).
• vm.mmap_min_addr = 65536
  Effect: Prevents data from being written to the first 64KB of memory. Makes the exploitation of "Kernel NULL Pointer Dereference" vulnerabilities more difficult.
• fs.suid_dumpable = 0
  Effect: Prevents "Core Dumps" from being created when SUID-bit programs crash. These dumps often contain sensitive information like password hashes from the shadow file or cryptographic keys.

3.2 Module Blocking Strategy (`/etc/modprobe.d/disable.conf`) (/etc/modprobe.d/hardeneding.conf)

Slarpx has blacklisted hundreds of kernel modules to reduce the attack surface.

CHAPTER 4: BOOTLOADER (GRUB) HARDENING AND BOOT SECURITY

Slarpx's security layers start before the kernel even loads. The configurations under the /etc/default/grub.d/ directory inject hundreds of hardening parameters into the Linux kernel.

4.1 CPU Mitigations (`40_cpu_mitigations.cfg`)

Highest-level protection settings for hardware-level vulnerabilities (Spectre, Meltdown, MDS) in modern processors are defined here.

• mitigations=full: Enables patches for all CPU vulnerabilities known by the kernel in the most secure (but slowest) mode.
• spectre_v2=on / spectre_bhi=on: Prevents Branch Target Injection and Branch History Injection attacks.
• l1tf=full,force: Aggressively closes the L1 Terminal Fault vulnerability in Intel processors.
• tsx=off: Disables the Intel Transactional Synchronization Extensions feature. TSX has been used as a vector in many "Speculative Execution" attacks.
• gather_data_sampling=force: Restricts the AVX instruction set to prevent Intel "Downfall" attacks or mandates protection if the microcode is updated.
• nosmt=force: (Optional/In a comment) Disables Hyper-Threading technology. This is the only way to prevent many "Cross-Thread" attacks (e.g., PortSmash).

4.2 Kernel Hardening Params (`40_kernel_hardening.cfg`)

Contains configurations for the kernel's memory management and internal security.

• slab_nomerge: Prevents the merging of kernel memory slabs of similar size. This makes it harder for a vulnerability in one area to affect another or for the memory layout to be predicted in "Heap Overflow" attacks.
• init_on_alloc=1 / init_on_free=1: Zeroes out memory when it is allocated and freed. This prevents "Use-After-Free" attacks and the exfiltration of sensitive data remaining in memory (Data Leaks).
• page_alloc.shuffle=1: Randomizes (shuffles) the usage order of memory pages.
• randomize_kstack_offset=on: Randomizes the starting address of the kernel stack for every system call (syscall).
• vsyscall=none: Completely closes vsyscall addresses, which are used as "ROP Gates" by attackers because they are obsolete and at fixed addresses.
• debugfs=off: Closes the DebugFS system, which can leak excessive information about the kernel's internal structure.
• panic_on_taint=0xC0924: Causes the system to immediately shut down if the kernel is "tainted" (e.g., when an unsigned driver is loaded or a critical error occurs).
• kfence.sample_interval=100: Activates the KFENCE system, which continuously monitors memory security errors (Heap out-of-bounds, etc.) with low performance overhead.
• mem_encrypt=on: Enables the SME (Secure Memory Encryption) feature on AMD processors to counter Cold Boot attacks at the hardware level.

4.3 Recovery and Console Restrictions (`41_recovery_restrict.cfg`)

Doors that could allow a physical attacker to gain root privileges are closed.

• GRUB_DISABLE_RECOVERY="true": Completely removes the "Recovery" mode from the GRUB menu.
• rd.emergency=halt / rd.shell=0: Prevents the system from opening an "Emergency Shell" if an error occurs during boot. Instead, the system shuts itself down ("halt"). Prevents a physical attacker from infiltrating the system by creating a boot error.

CHAPTER 5: ACTIVE DEFENSE SYSTEMS (ACTIVE DEFENSE)

This chapter describes the defense mechanisms specially developed for Slarpx.

5.1 Xennytsu : Exploit Killer Engine

Xennytsu is a behavioral-based "Process Killer" engine rather than a signature-based one.

5.1.1 Working Principles

The engine scans the /proc directory every O(SCAN_INTERVAL_US) (default: milliseconds). It calculates a "Threat Score" for each process. If the score exceeds the KILL_THRESHOLD (default: 50), the process is hit with a SIGKILL signal.

5.1.2 Detection Vectors

1. Suspicious Command Chains (Command Line Analysis):
   • Reverse Shell patterns: nc -e, bash -i, sh -i, socat exec.
   • Obfuscation: base64 -d, openssl enc -d.
   • Reconnaissance: cat /etc/shadow, nmap, masscan.
   • Payload Downloading: curl | bash, wget -O - | sh.
2. Environment Variable Hijacking (Env Analysis):
   If LD_PRELOAD, LD_LIBRARY_PATH, or LD_AUDIT are seen in a process's environment variables, this is considered a "DLL Injection" attack, and the score is immediately increased.
3. Namespace and Container Escapes:
   Commands like nsenter --mount, capsh --gid=0 are flagged as container or sandbox escape attempts.

5.1.3 Sample Scoring Table

• nc is running: +10 Points
• -e is in nc arguments: +50 Points (KILL!)
• curl is running: +5 Points
• curl is piped (|) to bash: +60 Points (KILL!)

5.2 Poison: Anti-Race Condition Engine

Poison is a file-system level "Delayer" using the Linux fanotify API.

5.2.1 Technical Mechanism

It captures access requests (OPEN, ACCESS) made to critical areas of the system (/etc, /usr/bin). If the accessing process is "suspicious" (fixed list of shells/interpreters), it waits the process at the kernel level for random microseconds using the usleep(RANDOM) function.

5.2.2 Defense Purpose

This mechanism targets TOCTOU (Time-of-Check to Time-of-Use) vulnerabilities. An attacker's exploit code expects a certain amount of time to pass between checking a file's permission and writing to the file (Race Condition). Poison disrupts the exploit's timing by extending this duration artificially and randomly, causing it to fail. It also makes file-access-based brute-force attacks practically impossible.

CHAPTER 6: NETWORK ARCHITECTURE AND FIREWALL

Network security is maintained by rules in the /etc/nftables.conf file and the slarpx-dns service.

6.1 Nftables Rule Set Analysis

6.1.1 Egress Filtering (Outbound Control)

Slarpx's most distinctive feature is its blocking of outbound traffic from the device.

• Permitted Targets:
  • TCP/80, TCP/443 (HTTP/HTTPS - Web Traffic)
  • UDP/TCP 53 (DNS - To Trusted Servers Only)
  • UDP 123 (NTP - Time Synchronization)
  • TCP 465/587/993 (Secure Email)
• Blocked:
  • Everything else (FTP, Torrent, IRC, Special Ports, Reverse Connect Shells).

NOTE: IPv6 is blocked at the kernel level through Grub to reduce the attack surface. However, if enabled, the firewall will also harden IPv6 traffic.

6.1.2 DNS Locking

To counter DNS poisoning and redirection attacks:

1. The /etc/resolv.conf file is fixed to Quad9 (9.9.9.9) DNS servers.

This is controlled by the slarpx-dns service.

CHAPTER 7: FILE SYSTEM AND PERMISSIONS STRUCTURE

The "Least Privilege" principle is applied to the file system.

7.1 Restricting Compilers

When an attacker infiltrates a system, they usually want to compile their own tools. To prevent this, development tools are restricted:

In this way, an exploit running with nobody or www-data privileges cannot compile and run C code within the system.

7.2 Immutable Files

The following files cannot be changed while the system is running (not just write-protected, but structurally locked):

• /etc/sudoers (Prevents manipulation of privilege tables)
• /etc/fstab (Prevents changing disk mount points)
• /etc/resolv.conf (Protects DNS settings)

This protection is provided through the permission-hardening service.

CHAPTER 10: MULTILAYER HARDENING

Slarpx's security is reinforced not only with special engines (Xennytsu/Poison) but also by hardening standard Linux components to the highest level.

10.1 APT Security (`/etc/apt/apt.conf.d/40hardened`) (`/etc/apt/apt.conf.d/40sandbox`) (`/etc/apt/apt.conf.d/40error-on-any`)

The following measures have been taken to prevent supply chain attacks and privilege escalation in the package management system:

• Sandbox & Isolation: Package download processes are delegated to a low-privileged user via APT::Sandbox::User "_apt".
• Network Security: Strict chain verification for HTTPS sources is performed by mandating Verify-Peer and Verify-Host.
• Integrity: AllowUnauthenticated and AllowInsecureRepositories are strictly turned off. Acquire::PDiffs "false" ensures data integrity by always downloading the full index.
• Anti-Forensics: .deb files downloaded with Keep-Downloaded-Packages "false" are automatically deleted to clear the disk footprint.

10.2 Resource Limits (`/etc/security/limits.d/hardened.conf`)

Resource limits are optimized to maintain system stability and prevent DoS attacks (e.g., Fork Bomb):

• Core Dumps: Taking memory dumps during application crashes is completely forbidden with hard core 0 (prevents sensitive data leakage).
• Process Limits: nproc limits (4096) meet the multi-process (sandboxing) needs of modern browsers while preventing uncontrolled process proliferation.
• Stack Size: The memory layout is fixed with stack 8192 (8MB KB), making overflow attacks more difficult.

10.3 Login Security and Faillock (`/etc/security/faillock.conf`)

PAM-level restrictions are applied to prevent brute-force attacks:

• Deny Threshold: deny = 5 (Account is locked after 5 consecutive failed attempts).
• Lockout Time: unlock_time = 300 (The locked account is inaccessible for 5 minutes).

10.4 Sudoers Hardening (`/etc/sudoers.d/hardening`)

The sudo configuration has been rewritten to increase security during authorized operations:

• Strict Umask: umask=0077 ensures that files created via sudo are only readable by root.
• TTY Enforcement: Non-terminal (script, etc.) manipulation of system calls and terminal hijacking attacks are prevented with requiretty and use_pty.
• Session Management: timestamp_timeout=2 (Sudo privilege drops after 2 minutes) and passwd_tries=3 (Failed password attempt limit).
• Path Hijacking: Users are prevented from running their own malicious binaries via sudo by mandating secure_path.

10.5 Shell Environment (`/etc/profile.d/hardening.sh`)

"Anti-Forensics" and restriction rules come into play from the moment the user session begins:

• Automatic Logout: Inactive terminals are automatically closed after 15 minutes with TMOUT=900.
• Leave No Trace (Ghost Mode): Command history is not recorded with HISTFILE=/dev/null and HISTSIZE=0. When the session is closed, the memory is cleared with history -c.
• Development Restriction: For normal users, compilers such as gcc, make, cc are blocked with aliases.
• File Permissions: Every new file created with the default umask 077 becomes readable only by its owner.

CHAPTER 8: PRIVACY VS SECURITY (PRIVACY LIMITATIONS)

PLEASE READ THIS SECTION CAREFULLY.

Slarpx is NOT a "Privacy" distribution. It is a "Hardening" distribution. The difference between these two concepts is of vital importance.

8.1 Fingerprinting Threat

Paradoxically, Slarpx's extreme security settings make you more visible on the internet.

• Fingerprint: Causes your network packets to look very different from a standard Windows or Android device. A website can look at these packet characteristics and say, "This user is using Slarpx."
• Browser Fingerprint: Unique security configurations also leave distinguishing marks on the browser.

8.2 Lack of Anonymity

• Unlike Tails OS or Whonix, Slarpx does not route traffic through the Tor network by default.
• Your IP address is clear.
• Your ISP can see which sites you enter (even if DNS is encrypted via SNI).
• Due to the strict firewall, Tor and VPN usage is restricted and requires a special configuration.

Limitations

XENNYTSU

• Cannot detect some attacks because it runs in userspace
• Vulnerable to targeted attacks; can be disabled
• Vulnerable to very fast attacks

CONTACT / LINKS

For project inquiries, contributions, or security reports, use the following channels:

• Lead Dev: root0emir@protonmail.com
• Project Github: github.com/slarpx
• SourceForge: sourceforge.net/projects/slarpx

APPENDIX A: FREQUENTLY ASKED QUESTIONS (FAQ)

Q: Can I use this system on my main computer (Daily Driver)?

A: No. Games won't work, Netflix/Spotify (DRM issues and browser restrictions) may cause problems, and printers won't work.

Q: I forgot my root password; can I recover it?

A: No. Changing GRUB boot parameters is locked, and Recovery Mode is off. If disk encryption (LUKS) is also present, your data is lost forever. This is a security feature (Anti-Forensics).

Q: Why was this system designed?

A: This system was developed for security research and hardening tests.