Hi, we are waiting for our security team to review the code which should
happen early this week. If you would like, I can build you a version of the
snapd snap that you can install locally to test out the fix. After the fix
has been approved by our security team we will also make the fix available
via a hidden branch that you can install from as well, but we don't want to
publish it in a hidden branch until we have confirmation from our security
team.

On Mon, Jan 25, 2021, 03:10 Gilad Reti <email address hidden> wrote:

> Hi @anonymouse67, are there any news?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1910456
>
> Title:
>   container management snaps should have Delegates=true in their systemd
>   unit
>
> Status in snapd:
>   Confirmed
>
> Bug description:
>   As reported to the ubuntu security team, and discussed in
>   https://github.com/docker-snap/docker-snap/security/advisories/GHSA-
>   798c-v3jq-h646, the docker snap's systemd unit for the dockerd process
>   should have Delegate=true in it to prevent systemd from reaping the
>   control groups for child processes (which in this case are docker
>   containers that are put into control groups which are separate from
>   the the docker snap) and moving the child processes back into the same
>   control group as the parent process that systemd is managing, which is
>   dockerd.
>
>   More concretely, not including Delegate=true in the systemd service
>   file means that after a systemctl daemon-reload is executed, docker
>   containers now have the same privilege level as dockerd, which is a
>   privilege escalation.
>
>   This was assigned CVE-2020-27352 by Alex Murray.
>
>   I have opened this private snapd bug, because this vulnerability
>   affects more than just the docker snap, it also affects any other
>   container management snaps, such as microk8s, Azure IoT Edge, AWS IoT
>   Greengrass and potentially others. The list of snaps affected can be
>   narrowed down to any snap which has been granted privilege to use a
>   "container management" interfaces, which are all super-privileged and
>   require a snap store assertion in order to be uploaded to the Snap
>   Store. The current list of affected interfaces is:
>
>   - docker-support (all variants)
>   - greengrass-support (with the "legacy-containers" flavor or with empty
> flavor)
>   - kubernetes-support (with the "kubelet" flavor or with empty flavor)
>   - lxd-support (though the LXD snap is not affected by this issue, we
> should fix the interface as if it was for consistencies sake) [1]
>
>   [1] This vulnerability specifically does not affect LXD though (or at
>   least it should not), because LXD is already using Delegate=true in
>   it's own generated systemd setup, as shown in this segment of the snap
>   packaging for LXD: https://github.com/lxc/lxd-pkg-snap/blob/latest-
>   edge/snapcraft/commands/daemon.start#L308. See also
>   https://github.com/lxc/lxc/issues/323 which is when the LXD project
>   first encountered the issue with Delegate and systemd.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snapd/+bug/1910456/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=snapd; status=Confirmed; importance=Critical;
> <email address hidden>;
> Launchpad-Bug-Information-Type: Private Security
> Launchpad-Bug-Private: yes
> Launchpad-Bug-Security-Vulnerability: yes
> Launchpad-Bug-Commenters: alexmurray anonymouse67 giladreti jdstrand
> Launchpad-Bug-Reporter: Ian Johnson (anonymouse67)
> Launchpad-Bug-Modifier: Gilad Reti (giladreti)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: anonymouse67
>