Skip to main content

Filesystem and Security Features in Nitrux

By Uri Herrera22 June, 2023November 25th, 2025Tutorial

In today’s tutorial, we’ll check all the filesystem, security, privacy, and anonymization features in Nitrux.

Difficulty: ★☆☆☆☆

📜 Table of Contents

    1. Default Security Policies in Nitrux
    2. XFS Features and Root Immutability in Nitrux
    3. Importing an OpenVPN connection in NetworkManager
    4. File Encryption in Nitrux
    5. Using F2FS Features in Nirux
      1. Native File Compression in F2FS
      2. Native File Encryption in F2FS

Default Security Policies in Nitrux

Nitrux enables the following security features and policies by default.

  1. Identity and Access Management
    • Policies related to user accounts, passwords, and authentication.
      • Deactivated Root Account: By default, the root account is disabled (has no password set) in both the Live session and the installed system to enforce accountability via sudo.
      • Stricter Password Expiration: We require passwords to be changed more frequently. The default expiration in Debian is 99,999 days; Nitrux reduces this by a factor of ~1,111 (approx. 90 days) to ensure regular credential rotation.
      • Increased Hashing Rounds: To mitigate brute-force attacks on modern hardware, we increased the number of hashing rounds to 60,000+ (up from Debian’s default of 5,000).
      • Enforced Password Complexity: Since version 2.8.1, Nitrux uses libpwquality to enforce strong credentials. Passwords must be at least eight characters long and include a mix of uppercase letters, lowercase letters, numbers, and symbols.
      • Brute-Force Protection: The system includes active countermeasures against guessing attacks:
        • No empty passwords allowed.
        • Account lockouts and time delays after failed attempts.
        • Preventing password reuse and restoring history.
  2. Kernel and Memory Hardening
    • Policies that mitigate low-level exploits and memory corruption vulnerabilities.
      • Disable Core Dumps: Application core dumps are disabled to save disk space and prevent sensitive RAM data (such as encryption keys, SSNs, or passwords) from being stored in persistent logs.
      • Memory Sanitization: The system immediately fills freed memory pages and heap objects with zeroes, preventing use-after-free attacks and data leaks from uninitialized memory.
      • Kernel Exploit Mitigation:
        • Disable Slab Merging: Prevents the kernel from merging memory slabs of similar sizes, making heap corruption exploits significantly harder.
        • Page Table Isolation (PTI): Mitigates speculative execution attacks such as Meltdown.
        • Randomize Kernel Stack Offset: Introduces randomness to the kernel stack offset on every system call to thwart memory prediction attacks.
        • Restrict Kernel Pointers: Hides kernel pointer addresses from non-privileged processes to prevent information leaks.
      • Attack Surface Reduction:
        • Disable Virtual Syscalls: Disables vsyscalls to reduce the attack surface for specific exploits and improve performance.
        • Enable BPF JIT Hardening: Hardens the Berkeley Packet Filter (BPF) Just-in-Time (JIT) compiler to mitigate JIT spraying attacks.
        • Disable SysRq Key: The physical SysRq key is disabled to prevent unauthorized low-level system commands.
  3. Network Security and Privacy
    • Policies that protect network identity and prevent spoofing.
      • MAC Address Randomization: Enabled by default to enhance privacy by preventing public networks from tracking the device’s unique hardware address.
      • IPv6 Privacy Extensions: The kernel generates temporary, mangled addresses for outgoing connections, hiding the original auto-configured IPv6 address from remote servers.
        • Anti-Spoofing Measures:
          • Reverse Path Filtering: Enabled to prevent IP spoofing and reduce vulnerability to DDoS attacks.
          • Disable Source Routing: Blocks source-routed packets to prevent attackers from bypassing network security controls.
  4. Application Sandboxing
    • AppBoxes (CLI) & other Executables: We utilize AppArmor and Firejail to restrict the capabilities of command-line tools and standard executables. This way ensures they operate with the principle of least privilege.
    • AppBoxes (GUI) & Flatpaks: Graphical applications (AppBoxes and Flatpaks) are isolated using Bubblewrap, providing a lightweight namespace sandbox that prevents unauthorized access to user data and system files.
  5. Network Security
    • Firewall Management: Nitrux includes UFW (Uncomplicated Firewall), which is managed via the Plasma Firewall GUI, making it easy to configure traffic rules.
    • VPN Support: NetworkManager comes pre-configured with plugins for OpenVPN, OpenConnect, and OpenFortiVPN.
    • WireGuard: Nitrux supports WireGuard for high-performance encrypted tunnels.
  6. Filesystem Integrity
    • Immutable Root: The system core is read-only by default to prevent tampering and ensure stability. However, users can still perform persistent modifications when necessary. For technical details, see XFS Features and Root Immutability in Nitrux.
  7. Password Management

XFS Features and Root Immutability in Nitrux

The root partition will use the XFS filesystem. This XFS-formatted partition will also use the following additional filesystem features (enabled by Nitrux™).

  • Allow the filesystem to place inodes anywhere in itself. Storing a file’s inode at the same location as its data improves performance.

Additionally, by default, Nitrux performs filesystem checks and repairs (if needed) during boot time.

Since Nitrux 2.6.0 (January 2023), the root directory is immutable by default. This change allows us to provide new versions of the distribution with a higher degree of certainty that no changes have happened to the root that might cause a conflict. We also want to avoid sudden issues caused by upgraded packages from a different origin than our repository, which we have little control over. However, we understand that there may be cases where users need to change something in the root directory.

  • ⚠️ Important: Any changes to the root directory should be explicitly made only through the shell session after running overlayroot-chroot.
    • ⚠️ Important: Mounting the devices’ pseudo-filesystem /dev is essential; otherwise, stuff like the CLI text editor we include in Nitrux (micro) will not work. Depending on the task, other filesystems must be mounted, e.g., /var/lib, /home, /tmpfs, etcetera. Only /proc, /run, and /sys are mounted by default.
  • 🔰 Information: After making the desired modifications, unmount the filesystems and exit.
sudo overlayroot-chroot

# Filesystems to mount; /dev is strictly necessary.

mount -t devtmpfs dev /dev

# To mount the partitions created by our Calamares configuration use findfs and the partition label.

mount -t auto $(findfs LABEL=NX_VAR_LIB) /var/lib

# (... do stuff...)

sync

# Unmount the partitions.

umount /dev /var/lib

exit

Changes are applied immediately to the root, i.e., the lower directory. However, for the changes to appear on the overlay, i.e., the upper directory, users must reboot the computer or reload the kernel using Kernel Boot (where supported); otherwise, any modifications won’t be visible.

Alternatively, users can temporarily boot with the immutability disabled. To do that, do the following steps.

  • ⚠️ Important: We must stress that the preferred method for modifying the root is the one above. If you know what you’re doing, use the technique below at your own risk.

    • Press E in the GRUB boot menu.
    • Using the arrow keys, navigate the text and find the kernel parameter overlayroot=tmpfs:swap=1,recurse=0, and change the parameter to overlayroot=disabled.
    • To continue the boot process, press F10.
    • After making the desired modifications, reboot.

Disclaimer: The user is responsible for any manual, permanent changes to the root using either of the methods described in this section. If these changes create conflicts during an upgrade using the Nitrux Update Tool System, users should resolve them independently. Please do not open issues regarding this use case in the bug tracker; they will be closed.

Importing an OpenVPN connection in NetworkManager

Since Nitrux 2.7.0, the distribution includes the OpenVPN plugin for NetworkManager. To import an OpenVPN connection using a file, i.e., example-vpn.ovpn, do the following.

  1. Open System Settings→Connections.
  2. Click the add (+) button and scroll down until you find “Import VPN connection…”
  3. Click the button “Create” and select your .ovpn file.
  4. Select the new VPN connection and ensure that in the connection type “Password with certificates (TLS)” is selected, then ensure that “Save password only for this user (cipher)” is selected for the secret key and VPN passwords.
  5. Activate the connection from the Connection settings (right-click → connect) or use the network icon in the system tray.
    • ⚠️ Important: If you use some public VPNs to protect your privacy, you might get a public IP address or at least be exposed to external connections. Once a public VPN is enabled, the firewalls in front of your computer no longer protect you. Nitru uses UFW by default and blocks incoming connections to alleviate this issue.
    • ⚠️ Important: Activating the connection immediately will cause a second dialog window to appear in the app, asking for the VPN password again after entering both passwords. To avoid this, log out and log in or reboot after adding the VPN connection.
  6. A dialog window will appear asking for two passwords: the VPN password and the secret key. Enter the VPN password and the secret key password.
    • 🔰 Information: Enter a password you’re familiar with. While it’s possible to use the user account password, we strongly recommend against it.
  7. (Optional) Pair the VPN with a primary connection so it connects automatically. Go to System Settings→Connections→Your Connection→General configuration, check the box “Connect automatically to VPN,” select the VPN, and click “Apply.”

Please note the following when importing an OpenVPN connection.

  • ⚠️ Important: IPv6 support depends on the VPN provider; this is not a bug in Nitrux. If the provider doesn’t support IPv6 tunneling, turn off IPv6 on the primary connection. Go to System Settings→Connections→Your Connection→IPv6, select “Ignored” as the method, and click “Apply.”

File Encryption in Nitrux

Nitrux provides multiple ways to encrypt data, including block-device encryption with dm-crypt (see Installing Nitrux), filesystem-level encryption with f2fs-crypt, and userland encryption tools like fscrypt.

  • A non-GUI option is fscrypt. fscrypt (not to be confused with f2fscrypt) is a tool for managing the native file encryption support of the ext4, F2FS, and UBIFS file systems.

Using F2FS Features in Nitrux

Since Nitrux 2.8.0, the home and /var/lib partitions will use F2FS instead of XFS. These F2FS-formatted partitions will also use the following additional filesystem features (enabled by Nitrux™).

  • Compression using zstd with compression at level 6. The primary goal is to reduce writes to extend the flash lifetime and, potentially, to achieve a slight increase in performance.
  • Verification of compressed blocks using a checksum to avoid corruption.
  • Enable a better garbage collector and asynchronous garbage collection.
  • Avoid synchronously updating access or modification times, which improves I/O performance and flash durability.
  • Native F2FS file encryption. The filesystem applies encryption at the directory level, and different directories can use different encryption keys. To use F2FS’s native encryption support.

Native File Compression in F2FS

F2FS allows the user to compress directories on demand; to do this, run the following command.

chattr -R +c $DIRECTORY

Native File Encryption in F2FS

F2FS provides native encryption via f2fscrypt and fscrypt.

  • If using f2fscrypt, do the following.
    • First, create the key in the keyring using a simple salt (or generate a random salt).
f2fscrypt add_key -S 0x1234
Enter passphrase (echo disabled):
Added key with descriptor [28e21cc0c4393da1]
  • Then use it to set the policy for encrypting the directory.
f2fscrypt set_policy 28e21cc0c4393da1 /encrypted/dir
Key with descriptor [28e21cc0c4393da1] applied to /encrypted/dir.
  • After each reboot, use the same command to set the key for decrypting the directory and its child directories.
f2fscrypt get_policy /encrypted/dir/
/encrypted/dir/: 28e21cc0c4393da1
  • If using fscrypt, do the following.
      • 🔰 Information: fscrypt is the preferred option over f2fscrypt; while both can manage F2FS native encryption features, f2fscrypt is deemed to be missing many essential features and is no longer actively developed.
    • Run fscrypt to create its configuration file and work directory.
sudo fscrypt setup
  • Then, run the following command.
    • Where $MOUNTPOINT is the mount point, e.g., /home.
sudo fscrypt setup $MOUNTPOINT
  • The command creates the $MOUNTPOINT/.fscrypt directory to store fscrypt policies and protectors.
    • ⚠️ Important: Never delete the hidden directory; otherwise, users will lose all access to encrypted files.

That’s it; this concludes today’s tutorial.

Post Views: 1,890
Next Post
Share