Hey,
I’ve been running NixOS for a little bit on three computers and was (a little) suprised at the lack of a good MAC solution for NixOS. I dabble in a bit of kernel development (in the security subsystem), and NixOS is great for building and testing different kernels. And it’s reproducibility is a game changer.
I’m making this post to gauge interest in a lesser known kernel feature/MAC framework called TOMOYO, that may be of interest to the NixOs community.
I may mess around and attempt an integration for NixOS for it if it’s interesting to anybody.
What the heck is MAC?
If you haven’t heard of them, Mandatory Access Control (MAC) systems are kernel-level security frameworks that restrict what processes can do regardless of traditional Unix permissions. Even if a process runs as root, MAC policies can prevent it from accessing files, devices, network resources, or executing other programs outside of what’s explicitly allowed. The idea is to limit the blast radius of bugs or compromises by enforcing the principle of least privilege. These days, these MAC frameworks are implemented as LSMs, or linux security modules, which are stackable (meaning multiple can be used). As of 2025, there are 9 (AppArmor, SELinux, Smack, TOMOYO, Yama, LoadPin, SafeSetID, Lockdown, BPF, and Landlock), 4 of which are MAC frameworks. (AppArmor, selinux, TOMOYO, and Smack)
On most Linux distributions, this MAC role is typically filled by SELinux (mostly RHEL family) or AppArmor (ubuntu and debian)
Why SELinux and AppArmor are so hard on NixOS?
There have been valient attempts (see 1 2) to integrate these into nixos, but they haven’t really had much success.
-
SELinux uses label-based policies and is very powerful, but it assumes mutable filesystem layouts, stable paths, and tight integration with distro packaging. Those assumptions don’t map well to NixOS’s immutable /nix/store and declarative rebuilds, and past integration attempts have struggled for that reason.
-
AppArmor is path-based and simpler in practice, but most existing profiles assume FHS-style paths like /usr/bin and /lib. On NixOS, the hashed store paths tend to make profiles unwieldy, fragile, or largely bespoke, and upstream profile reuse becomes difficult.
Because of this mismatch, NixOS currently lacks a MAC solution that feels native to its model rather than bolted on.
Why TOMOYO?
That led me to look at TOMOYO Linux, another Linux Security Module that’s been in the mainline kernel for a long time but is much less well known. TOMOYO is also path-based, but it’s explicitly designed around:
-
observing actual program behavior.
-
generating policies via a learning mode
-
and constraining execution based on those policies
TOMOYO is a path based lsm, rather than a label based, so the selinux labelling issue doesn’t pose a problem.
Interestingly, TOMOYO has a learning mode, which can be used to learn policies dynamically, and build them based on program behavior.
It does require a kernel compiled with CONFIG_TOMOYO, which is default disabled on NixOS (and most distros for that matter).
Latest Documentation: TOMOYO Linux 2.6.x : The Official Guide : Index
Has anyone used / worked with TOMOYO? I think it may more better than the FHS reliant apparmor or the file labeling approach of SELinux. It may fit well with NixOS.
Let me know your thoughts.