Comment 4 for bug 1910456

First off, I want to be clear that with all of the listed interfaces (with the exception of some of the flavors), the policy is considered 'advisory' and there are enough privileges to escape confinement. As such, I'm not convinced this should be granted a CVE because at some point, someone will point out how to break out, a CVE will be assigned and there will be no fix because that is precisely what the interface intends to give. As such I'd be more inclined to call this a normal bug in snapd. Alex, if you agree, we can burn the CVE.

The idea of adding Delegate=true when the affected interfaces are connected makes sense to me.

In terms of flavors, I would be in favor of only adding Delegate=true to affected flavors. I agree with your assessment to include it for all but autobind-unix in kubernetes-support. It should include it for both flavors of docker-support. Adding it for lxd-support makes sense for completeness, especially when we know that it intends to manage containers.

For greengress-support no-container (the legacy-container obviously needs it), rix means that runc will inherit the policies of the invoking process. This on its own is not enough IME to require adding Delegate=true, assuming the invoking process is coming from a snap and not unconfined.

I'll mention that system-files could be used in a manner to require Delegate=true if using 'write' with affected directories.

There is a question of classic snaps and container managers though, like microk8s. Should we add something to per command app yaml for Delegate=true for services? (we could have this flag for manual review in the store). I don't think this should block the proposed fix for strict snaps though.