I share mvo’s concern and agree we should consider the bpf branch which is undergoing active review now.
Jamie and I are working on https://github.com/snapcore/snapd/pull/3431 to unblock the revert. This PR fixes the immediate issue and also ensures that we won’t hit this issue going forward. There is more work (c.f. https://forum.snapcraft.io/t/versionized-profiles/) to solve all aspects of the problem but with the above PR we can move forward and will be safe for seccomp.
1 Like
The https://github.com/snapcore/snapd/pull/3431 branch is now merged and will be part of the next core snap build. @fgimenez - please run the nested suite with the core-revert test with the new code to verify that the branch actually fixes the revert issue we are seeing.
3 Likes
That was an epic PR, Michael! Thank you!
I did some testing with the nested suite now and found that we need a small extra PR: https://github.com/snapcore/snapd/pull/3517
On a refresh from the old snapd (pre-seccomp-bpf) to the new snapd
that uses the /var/lib/snapd/seccomp/bpf/*.bin code there is a race
condition on startup. When snapd starts it will create the new
security profiles. However all snap services (daemons) start in
parallel with snapd. So when a snap service like e.g. network-manager
runs it may not have a security profile yet. To fix this, snap-confine
needs to wait a little bit for the security profiles to appear.
We could make this wait conditional on uptime, i.e. only wait if the uptime is within the first 120 seconds or something.
1 Like