Versionized profiles

[niemeyer]

@jdstrand

This adds a bit of complexity to the implementation, for interface developers and for users/admins/auditors but I think this is likely acceptable.

This should not add any complexity to interface developers or to users/admins. Why would it?

For people trying to audit or debug the system, yes, they need to be aware that profiles need to change over time, but I’d argue that it’s actually better for auditing purposes that the alternative versions (older or newer) of the profile aren’t just going away.

@jdstrand

The proposed implementation might leave snapd in the critical path if the profiles aren’t present and snapd fails to start,

Again I don’t see how that’d be the case. It doesn’t seem to add any steps in that sense that aren’t already there. For example, today if the profiles aren’t in place when something starts, that something won’t start.

@jdstrand

I maintain the most important issue that the mknod/2.25 issues underscores is that the wrong profiles are being used with the wrong snapd/snap-confine and that we need to make sure that we always use the correct profiles.

Yes, this is the simplistic view of the problem. The more general view was described here:

The general statement of the problem is that software changes and the format of data they use also changes in incompatible ways. That incompatibility may sometimes be observed going forward, when version N+1 doesn’t understand the data of version N, but it’s more frequently observed when going backwards, when version N doesn’t understand the data of version N+1, because it’s easy to do a migration forwards, but harder to it backwards or introduce completely new ideas while preserving a limited understanding for the old.

@jdstrand

We can choose when to rev values in the inputs however we see fit from just syntax changes all the way to every new snapd version. The most determinism would be if revved every time, but we could start with simply at incompatible syntax versions and security-related or otherwise important profile changes.

That’s pretty much what is being proposed. One detail here is that “every time” is not just about snpad… it needs to take into account every single system dependency that plays a role: snapd, kernel, udev, etc.

@jdstrand

With the above, the system and policy should always be in a predictable, robust state,

Unfortunately the real world is not so kind. The robust and predictable state can easily get completely unusable after a simple boot onto a different kernel, which may happen completely behind the back of snapd.

@jdstrand

One idea would be to have a current symlink but we’d need to be careful to make sure it is up to date, perhaps by having the snap-generate-profiles command manage it. Another idea is to have a tool to introspect the system and report which digest would be used.

Yes, that’s the sort of idea being explored.