Versionized profiles

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.

The comment was really about apparmor_parser. Reading kernel capabilities should be faster than reading a file from disk.

But that won’t work unless inside a core device, right?

Thanks for your input! I started implemented this now in:

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:

build-id: 7a94e9736c091b3984bd63f5aebfc883c4d859e0
- capability
- caps
- dbus

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.

With that PR#3456 in place we can make the security profile re-generation conditional on the system-key:

I like this. apparmor-features is better than any implementation of apparmor version.

1 Like

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).

In the end we did implement a system-key mechanism for this.