I would say that this profile falls under the introductive comment saying that I generally don't know the rules which are relevant, and likely that those current rules are incorrect or useless. Hence I would not add a comment to say what to do except investigate on how /etc/pythonX.Y is generated on NixOS, if it ever is. Those present rules match a configuration where /etc/pythonX.Y is a symlink, like it is for instance the case with /etc/systemd/system -> /etc/static/systemd/system, but maybe NixOS/Python people would generate it otherwise, eg. environment.etc."pythonX.Y/foo".text = "bar". Maybe we should simply remove those rules and let correct ones be added by a later PR once the /etc/pythonX.Y setup has been elucidated.

No we don't use /etc/pythonX.Y. What kind of system-wide Python configuration could one expect?

I don't know why this is needed, but at least remove all old Python versions.

How does this work? It seems a bit scary to me to kill processes.

It seems scarier to me to have processes around actively circumventing the profiles, without that being obvious to the user

I suppose killing the unconfined confinable processes by default poses a certain risk of causing people who casually enable AppArmor (without looking at all of the module's options) and get their processes killed unexpectedly to forsake AppArmor with an unnecessarily poor opinion of it. As a compromise, I propose that killUnconfinedConfinables be disabled by default but the main security.apparmor.enable option's documentation recommend enabling it.

Also asking upstream: @stevebeattie @cboltz This procedure seems a bit unorthodox, what is your recommendation here?

It's indeed a bit unorthodox ;-)

I'm not familiar with NixOS, which makes recommending something a bit difficult. Please read the following lines with a grain of salt.

My recommendation not to use aa-teardown (and therefore not unloading any profiles) in my other comment is probably the most important part, because it will avoid that processes become accidently unconfined if someone runs systemctl restart apparmor.

That will however still leave the case of newly added profiles for already running processes, where killing/restarting the process is the only way to get them confined. Killing them by default is a secure way, but I'm not sure if the users will like it ;-)

I think the biggest difference from a apparmor perspective between NixOS and other Linux distributions here is that new versions executables will get a new path in the nix store, while common Linux distributions will update executables in place.

@8573 I've set killUnconfinedConfinables to true by default because it's how to get the running system to match the expectations declared in the NixOS configuration, and somehow "a secure way" as @cboltz put it. I've added warnings in the relase notes and the enable description. Also, AFAIK, when enabling AppArmor the first time, the system must be rebooted anyway to enable AppArmor in the kernel, and AFAICS the other main case that could trigger kills is in the rare situation when an AppArmor profile will be introduced/enabled for the first time into Nixpkgs.

I've also mentionned that killUnconfinedConfinables will unfortunately won't even work if we give names to the profiles in addition to their attachment paths because then /sys/kernel/security/apparmor/profiles will not expose the attachment paths and thus aa-status will not report processes from these paths as unconfined, and AFAICS it the same problem for attachment paths using regex, but because aa-status lacks support for these.

@cboltz Thanks for mentionning aa-remove-unknown, I've reinvented the wheel not knowing it existed ^^. Concerning my use of ˋaa-teardownˋ in ExecStop= I thing it's more faithful to what stopping means and is not problematic here because I'm using NixOS' reloadIfChanged= feature so that reconfiguring AppArmor shall only run ExecReload=. I'm also using ˋaa-teardownˋ in ExecStart= as a precaution because I want to be sure that only what is declared in the NixOS configuration is actually loaded into the kernel, I've had bad surprises in the previous AppArmor service with profiles lingering in the kernel and still active in addition to the profiles I wanted (in that case it happenned because apparmor_parser --remove had failed because of a missing included file, now this precise case should no longer happen but since the ExecStart= is normally only run at boot and only ExecReload= after, I prefer to be sure and remove all profiles upfront). So as I see it, a NixOS user should never have to run systemd start/stop/restart apparmor, and nixos-rebuild shall only run systemd reload apparmor.