Comment 17 for bug 1849753

>> An alternative without modifying snap-confine would be to have two snap-confine profiles, one for
>> strict and one for classic, and adjust the classic template to transition to the classic
>> snap-confine template which has rules allowing 'rw' access to files and 'unix' for sockets.
>
> To me this sounds like the easier of the two approaches - can you outline any particular
> (dis)advantages to either approach?

A pro for modifying snap confine means that it can still run under a restricted profile after it performs aa_change_profile(). The con is there is a short period when it isn't running under confinement. Without the investigation, it is not clear to me that the modification will achieve the objective of avoiding the file_inherit. The code changes to snap-confine would not be significant.

A pro for using a different template is that it requires no code changes and is less complex. A con is that the snap-confine policy is weakened when a classic snap executes another snap. In addition to a lessening of hardening around snap-confine, it is more difficult to reason about the confinement of snap-confine.

Considering that snap-confine is designed to be secure and not dependent on apparmor for its security, it is probably best to use the two-profile approach and make no code changes. This introduces no changes on systems with no classic snaps installed. While this will weaken the hardening of the safety net, there is nothing saying that we have to have a totally wide open policy for the snap-confine under classic. Eg, while we might have a wide 'rw' rules, we don't need 'x' or 'm' rules and we can use explicit deny rules for apparmor policy, libraries snap-confine uses, etc.