When trying to enable Apparmor on NixOS (I did some tinkering a while ago in Ubuntu), I got puzzled by the current state of affairs. With just security.apparmor.enable = true the profiles from apparmor-profiles aren’t loaded (aa-status shows only 4 ping profiles loaded; note that apparmor-profiles package is installed anyway). From what I understood, the only declarative loading method is to use security.apparmor.policies.<name> and paste the profile contents into profiles attribute. My questions:
What is meant by “policy”? Apparmor docs are quite vague on that term, option docs are somewhat confusing.
How can be profiles from apparmor-profiles (or any other package) loaded? Copying file contents e.g. via lib.readFile seems inefficient and inelegant to me.
on a side note, in the new year , i’m thinking of starting a new site, called Nix bounties or something , where you can offer crypto or $$$ or amazon wish list or some other currency to incentivise fixes for financial gain.
Nix is now at a size where this might be actually be viable.
@spacegreg, the only profiles from apparmor-profiles which have been adapted to NixOS so far are those in abstractions/ and tunables/, see nixos/modules/security/apparmor/includes.nix, they’re commonly used with the include keyword in applications’ profiles (eg. include <abstractions/base>).
Most of the content of profiles should be written in Nixpkgs’ pkgs/ in a postInstall defining an apparmor output. Those profiles use includes and apparmorRulesFromClosure as much as possible, and include a local/ customization (eg. include <local/bin.transmission-daemon>) which will then be optionally created by NixOS to add rules to the profile if need be (in this example, by setting security.apparmor.includes."local/bin.transmission-daemon").
Currently application profiles should be defined using security.apparmor.policies."bin.transmission-daemon".profile to include the profile from Nixpkgs (eg. include "${pkgs.transmission.apparmor}/bin.transmission-daemon"), but thinking about it, we should maybe load those profiles from environment.systemPackages like .desktop files, using environment.pathsToLink and environment.extraSetup.
The term policies in security.apparmor.policies does not really match something in AppArmor, I just needed a term to gather under the same name, the three options enable, enforce (whether to forbid or just report unallowed access), and profile (the rules for some executable paths).
Thanks a lot for the answer! It makes a lot of things clearer. Seems that there’s a separate effort needed to bring ready-to-use apparmor profiles to more packages.