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.
Has the state of AppArmor in NixOS changed in recent years? I’ve been trying to get AppArmor to do something useful for days now, to no avail. The profiles packages seem to be invalid, in that they’re installed and the paths they are watching are not valid nix paths, so none of the profiles actually do anything. I tried modifying a few of them directly, embedding them in profile = ‘’ … ‘’; within my configuration, but the efforts have been futile. The profiles are complex and nest other profiles, so you end up down a rabbithole of profiles that need to be modified to understand nix paths, in order for anything remotely complex to function. Even aa-genprof doesn’t really work, as it doesn’t understand systemd journal. I’m currently trying to get it to work with auditd, since auditd is supposed to be readable by aa-genprof.
I’m all for putting in some work to get this working, but I’m a bit out of my depth. The complexity of AppArmor ramps up fast and getting anything working is quite difficult. The profile packages seem to be in a state that they should probably be removed until they do something useful, that includes both the apparmor-profiles option and the roddhjav AppArmor profiles. None of them really do anything.
A bit off-topic for this particular thread, but I ran into much the same sorts of dead-ends, attempting to get SeLinux to work on NixOS. Does anyone know of efforts to get either of these working?