AppArmor on NixOS Roadmap

Development Security
21

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.

9 Likes
22

Hi @averdow thank you for this!

I am trying to use this but it seems apparmor doesn’t like the resulting apparmor file(s)

  security.apparmor.enable = true;
  security.apparmor.enableCache = false;
  security.apparmor_d = {
    enable = true;
    profiles = {
      vlc = "enforce";
    };
  };

Jun 21 02:27:54 x apparmor_parser[415255]: Cache miss: /nix/store/yjqwwln1rg6qiin3vh95k5bh5pm5zl95-apparmor-d-unstable-2025-05-27/etc/apparmor.d/vlc
Jun 21 02:27:56 x apparmor_parser[415255]: profile has merged rule with conflicting x modifiers
Jun 21 02:27:56 x apparmor_parser[415255]: ERROR processing regexs for profile vlc, failed to load
Jun 21 02:27:56 x systemd[1]: apparmor.service: Control process exited, code=exited, status=1/FAILURE
Jun 21 02:27:56 x systemd[1]: Reload failed for Load AppArmor policies.

It happens regardless of what profile I set to enforce and specifying no profiles lets apparmor load without a problem. Did I miss a step?

Thank you in advance

23

Hey, sorry for the necrobump, but I came across this thread after digging into security hardening measures for NixOS. This apparmor integration currently looks like the most mature tool yet for managing app security in nix, which is really cool!

Are there any recent updates on this roadmap? It looks like a few of the pending PRs have been merged since this was first posted.

I’m interested in helping with this project if there is still work to be done, I’m just not sure where to focus my attention.

3 Likes
24

There is certainly more work to be done, particularly in improving apparmor parser performance with mass aliases (Mass Aliases to the same target make the parser extremely slow (#460) · Issues · AppArmor / apparmor · GitLab) and making apparmor.d rules work properly with nix. The project is currently somewhat on hold while i write my bachelors thesis, i expect to be able to spend more time on this again start of next year. I also briefly considered writing my completely own parser. The parser just has to parse the rules into the format understood by the apparmor kernel module. It may therefore make sense to write a parser hyper-optimized just for mass aliases produced in nix closures while using the upstream parser for everything else. But that is a bit of a radical approach and needs more thought before it makes sense to have an implementation.

The PRs merged so far were the things that obviously make sense, no matter the specific approach we may later choose for our apparmor integration.

3 Likes
25

Hey, just wanted to report that after following the instructions of nix/common/apparmor at main · AaronVerDow/nix · GitHub I’m getting a bunch of cannot open shared object file errors when I try to open the programs I’ve applied the profiles to.

All the programs to be profiled are added in my home-manager closure & I’m using flakes, so that might be the cause of it.

My config snippet:

  security.apparmor.enable = true;
  security.apparmor.killUnconfinedConfinables = true;
  environment.systemPackages = with pkgs; [
    apparmor-parser
  ];

  security.apparmor_d = {
    enable = true;
    profiles = {
      btop = "enforce";
      vesktop = "enforce";
      "chromium.apparmor.d" = "enforce";
      "thunderbird.apparmor.d" = "enforce";

      okular = "enforce";
      libreoffice = "enforce";

      vlc = "enforce";
      mpv = "enforce";
      wireplumber = "enforce";
      pipewire = "enforce";
      pulseaudio = "enforce";

      speedtest = "enforce";
    };
  };

  # Add boot entry with AppArmor disabled in case of lockout
  specialisation = {
    no-apparmor = {
      configuration = {
        security.apparmor.enable = lib.mkForce false;
      };
    };
  };

  services.dbus.apparmor = "enabled";
  security.apparmor.enableCache = true;

The profiles are loaded, but the programs won’t open:

$ sudo aa-status            
apparmor module is loaded.
13 profiles are loaded.
12 profiles are in enforce mode.
   btop
   chromium
   mpv
   okular
   okular//gpg
   pipewire
   pulseaudio
   speedtest
   thunderbird
   vesktop
   vlc
   wireplumber
1 profiles are in complain mode.
   libreoffice
0 profiles are in prompt mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are in prompt mode.
0 processes are in kill mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.

$ okular
okular: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

$ chromium
/nix/store/5hp6560sp9ykk06fg7v55c3xcqy9cmq9-ungoogled-chromium-unwrapped-142.0.7444.162/libexec/chromium/chromium: error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: No such file or directory

$ mpv                                                       
/nix/store/l9k32vj2aczxw62134j1x0dsh569jz2l-bash-5.2p37/bin/bash: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory

$ vlc  
vlc: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

Has anybody an idea what might be the cause of this?

1 Like