Add nix os Info
30
nix-os-Info.md
Normal file
30
nix-os-Info.md
Normal file
@@ -0,0 +1,30 @@
|
||||
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:
|
||||
1. 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.
|
||||
|
||||
2. 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.
|
||||
|
||||
3. 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.
|
||||
Reference in New Issue
Block a user