mirror of
https://github.com/ryan4yin/nix-config.git
synced 2026-11-13 12:13:36 +01:00
Ryan Yin
0d800c4d9c
Nix 2.35's root nix-env -- used by nixos-rebuild to set the system profile -- calls saveMountNamespace(), which opens /proc/self/ns/mnt before remounting the read-only /nix/store writable. Those magic links have no connected path, so AppArmor cannot match them against any rule and denies the open with EACCES even in complain mode. The private mount namespace is then never created and nixos-rebuild aborts with: cannot remount "/nix/store" writable: not in a private mount namespace Adding flags=(attach_disconnected) lets AppArmor re-root those paths on / so the existing `file /**` rule matches. This also fixes any other sudo'd tool that needs namespaces (unshare, nsenter, bwrap, ...). Rolling this out to a host that already has the old profile loaded needs one deploy with --no-reexec, so the current system's Nix performs nix-env --set instead of the new system's; after that generation is active, plain `just niri` works and the Nix version is never rolled back.
Linux Hardening
Work in progress.
Application sandboxing (nixpak/bubblewrap) and Linux hardening knowledge for this repository. For
the repository security policy, architecture and audit status, see SECURITY.md;
for temporary exceptions and known gaps, see WORKAROUNDS.md.
Goal
- System Level: Protect critical files from being accessed by untrusted applications.
- Such as browser cookies, SSH keys, etc.
- Per-App Level: Prevent untrusted applications(such as closed-source apps) from:
- Accessing files they shouldn't.
- Such as a malicious application accessing your browser's cookies, SSH keys, etc.
- Accessing the network when they don't need to.
- Accessing hardware devices they don't need.
- Accessing files they shouldn't.
Current Structure
1. System Level
- AppArmor (
apparmor/): AppArmor profiles and configuration - Kernel & process hardening (
kernel-hardening.nix): sysctl baseline and unused-module deny list; rationale and verification live inSECURITY.md.
2. Per-App Level
- Nixpak (
nixpaks/): Bubblewrap-based sandboxing for applications- Firefox configuration
- QQ (Chinese messaging app) configuration
- Telegram Desktop configuration
- Modular system with reusable components
- Bubblewrap (
bwraps/): Direct bubblewrap configurations- WeChat sandboxing configuration
Current Implementation Status
| Component | Status | Notes |
|---|---|---|
| AppArmor Profiles | 🚧 WIP | Basic structure in place |
| Nixpak Firefox | ✅ Active | Firefox sandboxing via nixpak |
| Nixpak QQ | ✅ Active | QQ application sandboxing |
| Nixpak Telegram | ✅ Active | Telegram Desktop sandboxing |
| Bubblewrap WeChat | ✅ Active | WeChat specific sandboxing |
Directory Structure
hardening/
├── README.md
├── kernel-hardening.nix # sysctl baseline + unused-module deny list
├── apparmor/ # AppArmor security profiles
│ └── default.nix
├── bwraps/ # Direct bubblewrap configurations
│ ├── default.nix
│ └── wechat.nix
└── nixpaks/ # Nixpak application sandboxing
├── default.nix
├── firefox.nix
├── qq.nix
├── telegram-desktop.nix
└── modules/ # Reusable nixpak modules
├── custom-policy.nix
├── gui-base.nix
└── network.nix
System Hardening
- Apparmor: roddhjav/apparmor.d
- https://gitlab.com/apparmor/apparmor/-/wikis/Documentation
- AppArmor.d is a set of over 1500 AppArmor profiles whose aim is to confine most Linux based applications and processes.
- But all the profiles of AppArmor assume a FHS filesystem, which caused all apparmor policies takes no effect on NixOS.
- Apparmor on NixOS Roadmap:
- SELinux: too complex, not recommended for personal use.
Application Sandboxing
- Bubblewrap:
nixpak, more secure than firejail, but no batteries included.
- NixOS's FHSEnv is implemented using bubblewrap by default.
- Firejail: A SUID security sandbox with
hundreds of security profiles for many common applications in the default installation.
- https://wiki.nixos.org/wiki/Firejail
- Firejail needs SUID to work, which is considered a security risk - Does firejail improve the security of my system?
- Systemd/Hardening: Systemd also provides some sandboxing features.
NOTE
Running untrusted code is never safe, kernel hardening & sandboxing cannot change this; run
untrusted code in a VM on an isolated network. The threat model lives in
SECURITY.md.
References
- Harden your NixOS workstation - dataswamp
- Linux Insecurities - Madaidans
- Sandboxing all programs by default - NixOS Discourse
- Paranoid NixOS Setup - xeiaso
- nix-mineral: NixOS module for convenient system hardening.
- apparmor configs: