As for kernel interrogation, it certainly is possible on early boot to get the kernel capabilities we are interested in and put them in a file or hash for quick checks (along the lines of @mvo’s digest idea), but like you said, we need to now manage this file which adds complexity. Perhaps populating this file via a systemd one-shot early boot unit would make this robust-- but we’d have to consider cross-distro packaging to put that one-shot unit in place.
For apparmor_parser --version, I just remembered that /snap/core/current/usr/share/snappy/security-policy-version exists for similar reasons and it contains (along with some ubuntu-core-security-* cruft that should be removed) the apparmor version installed in the core snap. We’d have to read/parse that file but that is faster than an exec of apparmor_parser (@mvo’s digest could make that faster, but see above). Changes to this file don’t necessarily indicate syntax changes though-- indeed, it has the Ubuntu version and it will rev with SRUs, but there aren’t that many SRUs, so it may not be a problem.
Alternatively, if we decided the one-shot systemd early boot unit idea was the way forward, we could instead of looking at /snap/core/current/usr/share/snappy/security-policy-version run apparmor_parser --version as part of that one-shot.
Oh and you are right that apparmor version is not currently needed; it is a future consideration for if we introduce new syntax that impacts snappy policy.
It will generate a system-key string from the build-id and the apparmor-features of the running kernel. Its trivial to extend to new inputs as needed. The system-key looks currently roughly like this:
My plan (for now) is to just use this string directly (instead of hashing it) as it will making reasoning over /var/lib/snapd/system-key easier. Happy to hash it tough if that is preferable.
Whoops, I miscommented. This is kernel capabilities, not userspace. It is fine if we skip apparmor version for now since we can add it to the system key when the time is right (there is no reason to add it now since there are no syntax changes in any series 16 revision).
