Update to 19.03.15

[tianon]

No description provided.

[tianon]

Arg, @anonymouse64 looks like we need some new AppArmor adjustments for the containerd CVE mitigation... 😞

docker: Error response from daemon: /run/containerd/s/e15c35ef67476c11609c7576eee3549e767321cf8f56507989f5fe9ab1455439: mkdir /run/containerd/s: permission denied: unknown.

(That /run/containerd/s prefix is explicitly hard-coded intentionally to avoid unix socket path length issues and potential security issues with it being mutable.)

[anonymouse64]

fun... I will file a PR to snapd then

[anonymouse64]

@tianon do you have a specific CVE I can reference in the commit message?

[tianon]

Yes! That'd be CVE-2020-15257, documented in GHSA-36xw-fx78-c5r4.

[anonymouse64]

PR is at canonical/snapd#9764, after a little bit there will be a snapd snap you can download and install locally to test with this new version of the docker snap, could you validate that it fixes the issue?

[tianon]

Yeah, absolutely - I should be able to hack it into the pipeline here to ensure it works in GitHub's pristine environment (my local environment doesn't seem to catch these issues reliably, which is part of why I set up GitHub Actions in the first place 😄).

[anonymouse64]

BTW, it would be really cool if there was an equivalent github action here which built the snap from a PR and made it available for download so you can easily test a PR locally if you wanted 😉 it's as simple as something like this: https://github.com/canonical/etrace/blob/master/.github/workflows/snap.yml

[tianon]

BTW, it would be really cool if there was an equivalent github action here which built the snap from a PR and made it available for download so you can easily test a PR locally if you wanted it's as simple as something like this: https://github.com/canonical/etrace/blob/master/.github/workflows/snap.yml

Great idea - gonna rebase this on top of #14 once the current build test is finished. 👍

[tianon]

(moving back here to keep that snapd issue less noisy 😅)

So, in the context of canonical/snapd#9764 (comment), if we put something like assumes: [snapd2.48.2] in our file, does the store make sure we can't promote until that dependency is promoted, or is that something we have to monitor ourselves?

[anonymouse64]

Yes but unfortunately there is already a snapd 2.48 that does not have the fix, we can only do assumes for major versions not for patch versions like 2.48.2, so definitely using 2.48 in the assumes is better than not doing that but it's not 100% perfect unfortunately

[tianon]

Hmm, what triggers snapd to be refreshed from https://snapcraft.io/ after it's installed via APT?

(It seems snap refresh in my GitHub Actions didn't do it, so I'm not sure what would trigger that to occur and how common the situation I've currently got in this action is going to be for actual users? It seems APT gave me 2.48, which is new enough to satisfy my new assumes: but not new enough to actually satisfy the real dependency even though 2.48.2 does appear to be in the stable channel on snapcraft.io. 😞 😕)

[anonymouse64]

Well, the apt version is 2.48.2+20.04, and the snapd version is 2.48.2, so the apt version "wins" since "+20.04" is higher than "".

I'd recommend always installing the snapd snap to be sure you have the most up to date snapd.

[tianon]

Well, this is on Xenial, so I think doesn't even have 2.48.2 (yet?).

How common do you think this is going to be for users? In other words, how many users are likely to get broken if we move forward with this? 😬 😇

[tianon]

(I suppose the follow-up question is then whether we need to wait for 2.49+ so we can have a proper dependency relationship?)

[anonymouse64]

Well actually, as much as it saddens me to say this apparently we didn't end up cherry-picking the associated snapd PR to release/2.48 branch anyways so we need to either wait for a 2.48.3 (which may or may not happen), or we need to wait for 2.49. How important is it that this docker update is pushed through soon?

…

On Wed, Jan 6, 2021 at 5:34 PM Tianon Gravi ***@***.***> wrote: (I suppose the follow-up question is then whether we need to wait for 2.49+ so we can have a proper dependency relationship?) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABN2OLLPMKLU2UL4RFTLDJTSYTXPNANCNFSM4URB5PQQ> .

[tianon]

Well, this includes the mitigation for CVE-2020-15257 (GHSA-36xw-fx78-c5r4), which seems especially relevant for Snaps - they typically run with the host network namespace, right?

[anonymouse64]

Yes snaps run in the same network namespace as the host. I guess I leave it up to you how critical it is to fix this bug soon.

[anonymouse64]

@tianon on an unrelated note I realized I was mistaken earlier, you can use assumes: [snapd2.48.2] here, assumes does work with minor version numbers like that

[tianon]

Soooo, this is complicated. We need the latest snapd (which includes canonical/snapd#9764, necessary to make this bump even work), which in all the distro builds (https://packages.ubuntu.com/search?keywords=snapd) is 2.48.3 but in https://snapcraft.io/snapd is 2.48.2.1. 😬

I guess it's probably rare that someone is going to be updating docker but not updating snapd, so we're probably safe to just go with 2.48.2 for now?

[anonymouse64]

for the purposes of that pr, then yes assumes: [snapd2.48.2] is sufficient, snapd2.48.2.1 would be best, but that is currently broken (but will eventually be fixed by canonical/snapd#9923)

[anonymouse64]

oh wait sorry I forgot that pr didn't make it into 2.48.2, gosh this is all so confusing to keep track of

[anonymouse64]

well I can say for sure for sure that snapd2.49 will have that pr in it, 2.49 is in beta now and should move to candidate/stable within the next 2 weeks (2.49 was blocked by the CVE)

[anonymouse64]

and checking in on the upgrade situation, we still have a sizable ( more than 10% of total userbase ) install base of 2.48.2 on core/snapd snaps (across all devices, not necessarily docker snap users), so if we do include 2.48.2 in the assumes it's possible that folks are still on 2.48.2 and as such they won't be required to update snapd before installing docker.

at this point I'm feeling like since we pushed out something that triggered refreshes to deal with that CVE, we should just make this wait until 2.49 :-|

[tianon]

Heh, nice! I'm honestly a little confused why all the suites of Ubuntu got 2.48.3 but the store got 2.48.2.1 which appears to be the same underlying version? I would've expected that to be the other way around (if anything), TBH.

I think the likelihood of folks updating docker but not having updated snapd is terribly low, but it would be nice to have that actually validated (without having to wait another week or two to get there). I guess we could just plan to tell anyone who complains to update their snapd? I don't get to see https://snapcraft.io/snapd/metrics, but I have to imagine the number of (data reporting) users who didn't get the bump by now is pretty tiny. I'd worry more about users who aren't consuming snapd from the Snap, but their mitigation path is pretty straightforward. 😅

[anonymouse64]

In all likelihood, I think you're correct in that the number of affected docker snap users will likely be very small, so we are probably good to just go with assumes: [snapd2.48.2], and then after 2.49 is out maybe we can revisit and bump it again to 2.49 to be super extra sure