[PATCH 13/36] cmd/libsnap-confine-private: Tighten AppArmor label check

Only consider snap-confine as confined by AppArmor when the AppArmor label
matches an expected path location for the snap-confine binary, rather than
just if the label is not "unconfined". This ensures snap-confine will fail
to execute if it is executed under a more permissive AppArmor profile than
expected.

Signed-off-by: Alex Murray <alex.murray@canonical.com>
Gbp-Pq: Topic cve202144730
Gbp-Pq: Name 0013-cmd-libsnap-confine-private-Tighten-AppArmor-label-c.patch

[PATCH 12/36] cmd/libsnap-confine-private: Don't fail open on apparmor confinement

aa_is_enabled() can be made to fail by setting low open file limits or
similar - in this case, snap-confine would continue executing as though it
were unconfined. However, this can be detected by checking errno more
closely - so only fail open when we know AppArmor either is not supported
or has been explicitly disabled at boot and otherwise fail closed.

Signed-off-by: Alex Murray <alex.murray@canonical.com>
Gbp-Pq: Topic cve202144730
Gbp-Pq: Name 0012-cmd-libsnap-confine-private-Don-t-fail-open-on-appar.patch

[PATCH 11/36] cmd/libsnap-confine-private: Defend against hardlink attacks

When snap-confine goes to execute other helper binaries (snap-update-ns
etc) via sc_open_snapd_tool(), these other binaries are located relative to
the currently executing snap-confine process via /proc/self/exe. Since it
is possible for regular users to hardlink setuid binaries when
fs.protected_hardlinks is 0, it is possible to hardlink snap-confine to
another location and then place an attacker controlled binary in place of
snap-update-ns and have this executed as root by snap-confine. Protect
against this by checking that snap-confine is located either within
/usr/lib/snapd or within the core or snapd snaps as expected.

This resolves CVE-2021-44730.

Signed-off-by: Alex Murray <alex.murray@canonical.com>
Gbp-Pq: Topic cve202144730
Gbp-Pq: Name 0011-cmd-libsnap-confine-private-Defend-against-hardlink-.patch

[PATCH 10/36] cmd/libsnap-confine-private: Fix use of uninitialised variable

Ensure xdg_runtime_dir_env is zero initialisd in
sc_call_snap_update_ns_as_user() otherwise when XDG_RUNTIME_DIR is not
defined the uninitialised contents of this buffer will be passed to
snap-update-ns. This is unlikely to be an issue in practice as
snap-update-ns is quite defensive in terms of environment variable handing
already.

Signed-off-by: Alex Murray <alex.murray@canonical.com>
Gbp-Pq: Topic cve202144730
Gbp-Pq: Name 0010-cmd-libsnap-confine-private-Fix-use-of-uninitialised.patch

man-page-sections

Gbp-Pq: Name 0010-man-page-sections.patch

[PATCH 7/9] i18n: use dummy localizations to avoid dependencies

Upstream snapd uses the github.com/ojii/gettext.go package for access to
translation catalogs. This package is currently not available in Debian
and prevents building the package. As such, replace the real
implementation with a simple dummy one that always uses the English
input strings.

Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
Gbp-Pq: Name 0007-i18n-use-dummy-localizations-to-avoid-dependencies.patch

[PATCH 6/9] systemd: disable snapfuse system

Upstream snapd uses an elaborate hack to bundle squashfuse under the
name snapfuse, and built as a fake go package. This component is not
available in Debian where bundling elements is not allowed.

Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
Gbp-Pq: Name 0006-systemd-disable-snapfuse-system.patch

[PATCH 5/9] advisor,errtracker: use upstream bolt package

Upstream snapd uses a fork of the bolt package that carries additional
patches for bugs that were discovered by snapd developers. Bolt itself
appears to be an abandoned project and is not accepting any new patches.

In various distributions the upstream bolt package may or may not have
been patched but the forked version was definitely not packaged. As
such, to build snapd in Debian the upstream bolt package name must be
used.

Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
Gbp-Pq: Name 0005-advisor-errtracker-use-upstream-bolt-package.patch

[PATCH 4/9] cmd/snap: skip tests depending on text wrapping

Upstream snapd contains tests that check the output of various commands
along with the --help command-line argument. The output is wrapped to
match terminal width and for readability. The algorithm for wrapping
has apparently changed across versions of github.com/jessevdk/go-flags.

Since this test is not critical for anything it can be disabled to let
the package build.

Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
Gbp-Pq: Name 0004-cmd-snap-skip-tests-depending-on-text-wrapping.patch

[PATCH 3/9] cmd/snap-seccomp: skip tests that use -m32

Apparently Debian's amd64 compiler somehow cannot compile -m32 mode
binaries. The compilation error is:

multipass@debian-10:~/packaging/snapd/cmd/snap-seccomp$ go test
cannot build multi-lib syscall runner: exit status 1
In file included from /usr/include/errno.h:25,
 from /tmp/check-3806730340354206876/1/seccomp_syscall_runner.c:3:
/usr/include/features.h:424:12: fatal error: sys/cdefs.h: No such file or directory
 #  include <sys/cdefs.h>
    ^~~~~~~~~~~~~
compilation terminated.
OK: 2 passed, 11 skipped

I was unable to resolve this issue, let's disable this test until we can get to
the bottom of it.

Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
Gbp-Pq: Name 0003-cmd-snap-seccomp-skip-tests-that-use-m32.patch

[PATCH 2/9] cmd/snap-seccomp: skip tests that fail on 4.19

It seems that the Debian 4.19.0-1 kernel contains a regression in
seccomp execution. While this issue is investigated in parallel along
with the security team, the release of updated snapd package should not
be held by this issue.

Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
Gbp-Pq: Name 0002-cmd-snap-seccomp-skip-tests-that-fail-on-4.19.patch

[PATCH 1/9] cmd/snap-seccomp: use upstream seccomp package

Upstream snapd uses a fork that carries additional compatibility patch
required to build snapd for Ubuntu 14.04. This patch is not required with
the latest snapshot of the upstream seccomp golang bindings but they are
neither released upstream nor backported (in their entirety) to Ubuntu
14.04.

The forked seccomp library is not packaged in Debian. As such, to build
snapd, we need to switch to the regular, non-forked package name.

Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
Gbp-Pq: Name 0001-cmd-snap-seccomp-use-upstream-seccomp-package.patch

snapd (2.37.4-1+deb10u1) buster-security; urgency=medium

   * SECURITY UPDATE: local privilege escalation
    - d/p/cve202144730: Add validations of the
      location of the snap-confine binary within snapd.
    - d/p/cve202144730: Fix race condition in snap-confine
      when preparing a private mount namespace for a snap.
    - CVE-2021-44730
    - CVE-2021-44731

[dgit import unpatched snapd 2.37.4-1+deb10u1]

Import snapd_2.37.4-1+deb10u1.debian.tar.xz

[dgit import tarball snapd 2.37.4-1+deb10u1 snapd_2.37.4-1+deb10u1.debian.tar.xz]

Import snapd_2.37.4.orig.tar.xz

[dgit import orig snapd_2.37.4.orig.tar.xz]