Table of Contents
files in the NixOS immutable store ( /nix/store) can be called, executed, and, under specific circumstances, exploited, despite being read-only. While the immutability makes it nearly impossible for malware to modify existing system binaries, it does not prevent malicious actors from exploiting vulnerabilities within those binaries or using them for privilege escalation. Here is a breakdown of how these files are managed and exploited:
- The Nature of Immutability in NixOS
-
Read-Only Store: The /nix/store directory is typically mounted as read-only. Files within it cannot be altered after they are created. -
Unique Paths: Files are identified by a hash of their dependencies. If a configuration changes, a new version is created in a different, immutable directory. -
No /bin or /usr/bin: Standard Linux directories like /usr/bin are mostly absent. Instead, system tools and libraries are symlinked from the /nix/store.
- How Immutable Files Can Be Exploited
-
Vulnerable Binaries: If a software package in the Nix store has a known CVE (vulnerability), it can still be executed and exploited by an attacker, even if the file itself cannot be modified. -
Privilege Escalation: Researchers have identified vulnerabilities in the Nix package manager itself that, when combined, can allow a regular user to gain root privileges. -
Race Conditions: Exploits can leverage the garbage collector (nix-collect-garbage) to delete files in /nix/store or manipulate symbolic links during system updates. -
Misconfiguration Exploits: While the store is read-only, if a user configures a service to run with high privileges and it uses a vulnerable library, the system can be compromised. -
Writable /tmp Directory: Attackers might exploit how services handle temporary files in writable locations (like /tmp) to bypass the read-only protection of the /nix/store.
- Security Implications
-
Persistence Limits: Malware cannot easily modify a binary in the store to establish persistence. However, an attacker can point the system to a new malicious binary, as they can add new, albeit immutable, files to the store. -
Secrets Exposure: Although binaries are read-only, they can be world-readable. If secrets or keys are accidentally included in the store, they can be read by any user.
How to Mitigate Risks
-
Use vulnix: Use tools like vulnix to scan the Nix store for packages with known vulnerabilities. -
Set Up Secrets Management: Use proper secret management tools (e.g., agenix or sops-nix) instead of placing secrets directly in Nix configuration files. -
Sandboxing: Utilize containerization or sandboxing (like bubblewrap) to limit the impact of a compromised application. -
Update Regularly: Since updates are atomic, regular system rebuilds ensure you are using the latest, patched versions of software.
In summary, the immutability in NixOS protects against traditional file-tampering malware, but it is not a silver bullet against application-level vulnerabilities or privilege escalation.
Concerning ASLR
Address Space Layout Randomization (ASLR) is active on NixOS, just like in other modern Linux distributions. It is a system-level security feature enabled by default to mitigate exploits by randomizing memory locations for stacks, libraries, and executables. NixOS relies on the Linux kernel’s implementation of ASLR.
-
Default Behavior: ASLR is enabled by default to protect memory from unauthorized access. -
Requirements: For full ASLR protection, binaries must be compiled as Position-Independent Executables (PIE). -
Debugging Note: Using tools like gdb may automatically disable ASLR while debugging, which might cause memory addresses to appear consistent. -
Verification: You can verify the status by checking cat /proc/sys/kernel/randomize_va_space (values of 1 or 2 indicate enabled).
Concerning IOMMU
NixOS can take full advantage of IOMMU (Input-Output Memory Management Unit) to enable hardware-accelerated virtualization, commonly used for GPU passthrough (VFIO). NixOS's declarative configuration model actually makes setting up complex IOMMU scenarios, such as passing a GPU to a Windows VM for gaming, quite manageable compared to imperative distributions. How to Enable IOMMU in NixOS To activate IOMMU, you must modify your /etc/nixos/configuration.nix to include necessary kernel parameters for your CPU.
Enable in BIOS: First, ensure VT-d (Intel) or AMD-Vi (AMD) is enabled in your motherboard BIOS.
Configure configuration.nix: Add the following to your configuration:
nix
boot.kernelParams = [
"intel_iommu=on" # Use "amd_iommu=on" if you have an AMD CPU
"iommu=pt" # Optional: Often helps with performance/stability
];
Reboot: Rebuild your system (nixos-rebuild switch) and reboot to activate the IOMMU.
Verify: Check if IOMMU is active by running:
journalctl -b | grep -i -e iommu -e dmar.
Key IOMMU Use Cases in NixOS
GPU Passthrough (VFIO): You can pass a dedicated PCIe graphics card to a virtual machine (e.g., via QEMU/KVM) to get near-native gaming performance, allowing you to run Windows inside NixOS with high-performance graphics.
PCIe Device Isolation: IOMMU groups are essential for security and stability when passing devices (NICs, GPUs, USB controllers) directly to VMs.
VFIO Drivers: You can configure NixOS to load the vfio-pci drivers early in the boot process to grab a GPU before the host X11/Wayland desktop does.
Relevant NixOS Configurations
Modules: You need to load the VFIO kernel modules:
nix
boot.kernelModules = [ "vfio" "vfio_iommu_type1" "vfio_pci" "vfio_virqfd" ];
Device Blacklisting: Often, you need to blacklist GPU drivers (like nvidia or amdgpu) for the guest GPU to prevent the host from using it.
Libvirt/Virt-manager: NixOS has excellent support for virt-manager and QEMU, making it easy to manage VMs.
For detailed, step-by-step instructions, the official NixOS Wiki PCI Passthrough page is the best resource.