Comment 37 for bug 1910456

Gilad, thanks for sharing that - there are just a couple changes that would help clarify this:

Replace:

  This issue was a result of bad configurations in Canonical’s snap

With:

  This issue was a result of bad configurations generated by Canonical’s snapd

Also in regards to the following part:

  If you are using snap with any of these packages it is recommended that you upgrade your system immediately.

You may not know, but by default snaps automatically refresh to the latest version every 4 hours. So there is no manual step a user needs to take to 'upgrade their system immediately' as in most cases they will have automatically refreshed to the fixed version by the time they read this blog post - if they want to ensure they have refreshed to this version though they can run `snap refresh` to force it to happen immediately.

Also I think the following part is a bit unclear:

-------

  When installing a service through Snap, Snap forwards the service registration requests to systemd and registers it as a service under the following name structure:

    snap.<package_name>.<service_name>.service

  When snap registered the dockerd service, the Docker Snap package did not request a systemd’s cgroup delegation, leaving the cgroup management in the hands of systemd. Moreover, the Snap daemon (snapd) did not expose this option to packages installed via Snap at all, thus any service installed via Snap had its cgroups managed by systemd. In particular, Docker, when installed via Snap, is vulnerable to this escape.

---

So to clarify this I'll explain how snapd works with systemd - when a snap is installed that contains a daemon, snapd generates a systemd unit file on behalf of the snap daemon. In this case, since snapd had no awareness of/support for the Delegate property of systemd units, there was no way for the docker snap to request this functionality. I just want to ensure it is clear that it is snapd that is at fault here, not the snaps like Docker themselves.

As such you should then also change the following bit:

  Due to a bug in Snap’s Docker package, the Docker daemon is no longer allowed to manage cgroups for its containers, while systemd is taking ownership of the containers’ cgroups, to cause a misconfiguration.

To instead be something like:

  Due to this missing feature in snapd, the docker snap is not able to indicate to systemd that it will manage cgroups on behalf of its containers itself, and so systemd takes ownership of these cgroups, resulting in this misconfiguration.

Also there are easier ways to trigger apport to run on the host than having to write a program which causes a segmentation fault - instead you can just send the SIGSEGV (or SIGABORT) to an existing process - ie running the following from a terminal will cause Apport to be spawned:

 bash -c 'kill -SIGABRT $$'

Finally, I think the conclusion is a bit sensationalist - given that snaps auto-refresh (including snapd itself), the majority of users will have their snapd updated and hence patched against this vulnerabilility automatically. Also this only affects users of either the docker snap or other snaps which are container managers like the few mentioned in your opening - of these the docker snap is the most widely deployed but even it doesn't have millions of users - the real number is an order of magnitude lower than this.

So this doesn't affect everyone using snaps, only those using the docker snap etc *and* who may be running untrusted/malicious containers. If you are running trusted workloads as docker containers then there is no risk from this vulnerability.

Thanks again for sharing this ahead of the CRD, I really appreciate it.