Congrats on getting this to work for you, and good to see more people taking an interest!
apparmor-d is in nixpkgs (under the name roddhjav-apparmor-rules), but basically unusable: it is missing the path patching that i am applying to my package, and it doesn’t use the preprocessor build. This means all the paths expect FHS-compliance, which is obviously wrong. So the package needs fixing, but i didn’t do this until i considered other things.
Hacking the nix store to be treated as if it were an FHS-compliant root directory is inherently kind of unsafe: A user that has access to the nix daemon can inherently put arbitrarily named packages into the store. To mitigate this, i wrote aa-alias-manager, with the goal of providing a “joint root alias” for a built nixos system generation. The problem is: AppArmor is attrociously slow with parsing mass aliasing. The way forward is to build this alias list (maybe even as part of the closure-info build in nixos), and then prebuild it. This requires a custom parser specifically optimized to deal with this mass aliasing, which can then write e.g. to the global apparmor cache. Roddhjav was working on custom parsers in go for his rule repository, but considering in nix we can generate arbitrary input and just have to match the output, some serde writer syntax might also be possible. This does however take time, time i do not currently have.
I also managed to make libapparmor fully bit-reproducible. The last piece was pycache generation during make tests depending on actual build time, which was fixed in libapparmor/test: avoid writing __pycache__ (!1697) · Merge requests · AppArmor / apparmor · GitLab.
So progress is happening, but it is slow. The parser/alias optimisations are probably the one most important thing, because aliases are the “proper” way to use FHS-intended rules for a non-FHS system.