AppArmor on NixOS Roadmap

I wouldn’t be quite that pessimistic.

This is basically the same problem as systemd hardening and we have been able to roll that out to NixOS modules’ services to a decent degree on a best-effort basis.

In the long term, I’d ideally like to see upstreams maintain the aa profiles for their apps because they know best what those should and shouldn’t be able to do. (Just like with systemd hardening.)

I feel like that should become more prevalent because I see the Zeitgeist moving towards more hardening as we become aware of just how insecure our (in other respects awesome) systems are.

I’m under no illusion that we won’t get every upstream to do so though, so I think an independent collection of permissively licensed (i.e. apache-20) profiles would be the next best thing.
This should ideally be a cross-distro effort as, for any given program, the associated aa profile should dictate the same policy on basically any distro.

It’s also not like we need to provide complete aa profiles for each and every program. You could provide default rules for all programs that provide some basic hardening and work for 99% of them and then manually fix the remaining 1%. That 1% would be much more manageable.

What I mean by “basic hardening” would be preventing any old program from accessing high-value targets such as SSH keys, GPG keys, browser cookies, executables (user bin, bashrc, systemd user services) or perhaps even personal documents.
If we could produce profiles that only allow the few % of programs that actually need to be able to access these, that would be an immense security benefit already IMHO.

14 Likes