[PATCH 11/36] cmd/libsnap-confine-private: Defend against hardlink attacks
authorAlex Murray <alex.murray@canonical.com>
Wed, 17 Nov 2021 03:57:22 +0000 (14:27 +1030)
committerAlex Murray <alex.murray@canonical.com>
Tue, 29 Nov 2022 12:01:21 +0000 (12:01 +0000)
commit0342c4af2500bb62cf3ab4e22625d72824d9836e
tree1c5f5446de95af2152b005e0be9ff23cb8726a33
parent28d51ce76fd3f91173cbd4ec9020e1728eb27915
[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
cmd/libsnap-confine-private/tool.c
cmd/libsnap-confine-private/utils-test.c
cmd/libsnap-confine-private/utils.c
cmd/libsnap-confine-private/utils.h