* snap-bootstrap: wait in `mountNonDataPartitionMatchingKernelDisk`
The current snap-bootstrap has a race when mounting the seed
partition in `mountNonDataPartitionMatchingKernelDisk` on EFI
systems.
The code determines the partUUID of the disk that booted the
kernel by reading the EFI LoaderDevicePartUUID variable. However
there is no guarantee that this partition is available when
snap-bootstrap runs, the kernel may still enumerate the HW.
This can be observed on a fast NUC when booting from a USB
stick.
Note that the `the-tool.serice` already has a
"After=systemd-udev-settle.service" set but that is still
racy because any `udev settle` (or `udev trigger --settle`)
is racy, the only option is to poll for the part uuid to
appear.
This is a minimal commit to avoid too much churn in code.
Thanks to Sertac for reporting this bug.
* snap-bootstrap: rework waitPartSrc to improve testing (thanks to Alberto and Ian)
* snap-bootstrap: show a log message if waitPartSrc needs to wait
If waitPartSrc needs to wait for the device this commit makes it
show a logger.Noticef() message. The message is only shown once
because waiting for the device is usually super quick and if it
is not that is most likely an error anyway so spamming the
terminal will not help.
* snap-bootstrap: add test that ensures that if no waiting is needed for partSrc no log message is displayed
* snap-bootstrap: rename waitPartSrc -> waitFile
* snap-bootstrap: fix time.Duration() casting on 32bit systems
On some architectures, such as aarch64, we've seen the ld.so interpreter to be
named like lib-linux-aarch64.so.1. However, snap-confine's AppArmor profile
prevents that path from being loaded, thus breaking execution of snaps. The
following denial was observed on affected systems:
audit: type=1400 audit(1632477434.031:8902): apparmor="DENIED" operation="file_mmap"
namespace="root//lxd-happy-impish_<var-snap-lxd-common-lxd>"
profile="/snap/snapd/12886/usr/lib/snapd/snap-confine"
name="/usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1"
pid=1101743 comm="snap-confine" requested_mask="m" denied_mask="m"
fsuid=1000000 ouid=1000000
Fixes: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1944004
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Clang 13.0 generates this warning:
libsnap-confine-private/cgroup-support-test.c:282:15: error: variable 'p' set but not used [-Werror,-Wunused-but-set-variable]
char *p SC_CLEANUP(sc_cleanup_string) = NULL;
^
1 error generated.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Old apparmor_parser complains about that. OTOH things worked without that.
On 16.04:
+ apparmor_parser -r squashfs-root/etc/apparmor.d/usr.lib.snapd.snap-confine.real
AppArmor parser error for squashfs-root/etc/apparmor.d/usr.lib.snapd.snap-confine.real in squashfs-root/etc/apparmor.d/usr.lib.snapd.snap-confine.real at line 81: Invalid capability bpf.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
The pre 5.11 kernels used to use rlimit memlock for accounting of memory used by
BPF objects such as maps and programs. This has been fixed in 5.11 with
https://lkml.org/lkml/2020/7/24/1318 where the accounting is better. However,
some systems such as Debian Sid still use older kernels. That combined with a
very low rlimit memlock setting (64k) results in snap-confine erroring out due
to -EPERM on bpf(BPF_MAP_CREATE, ..). Further investigation showed that the
memlock size of the BPF map we create (9+1 bytes * 500 entries) is 11 (45k)
pages on those systems. While on systems sporting 5.11 kernel, the memlock as
reported by bpftool is just 2 pages (8k).
The patch bumps the memlock limit to 512k when necessary. Which is enough to fit
the map and a beefy program.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Create maps, pin then and get file descriptors as root, such that we don't have
to mess with CAP_BPF.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
The gdb helper shims execute inside the snap mount namespace, but may come from
the snapd package on the host, or have otherwise been built on the host system.
In order to avoid dependency on a specific version of glibc on the host, build
both binaries statically.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* cmd/snap-confine: determine CURRENT_TAGS support, check current tags
Try to determine whether the libudev/libsystemd supports CURRENT_TAGS which has
been introduced in systemd v247:
f6278558da/NEWS (L1037-L1119)
This comes in pair with TAGS becoming sticky, what means that our checks no
longer behave correctly as the tags do not go away.
If the library supports current tags, use the dynamically collected symbol to
double check that the device is really currently tagged for a snap. The
implementation introduced in v247 correctly checks whether the running systemd
supports current tags and otherwise falls back to looking at TAGS property.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* tests/main/security-device-cgroups: tweak the tests to better handle sticky udev TAGS
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* cmd/snap-confine: let the linker fill the symbol
Instead of dlopen() and looking for the symbol ourselves, define a weak symbol
and let the dynamic linker do the work.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* cmd: snap-confine does not need to link with libdl anymore
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* cmd/snap-confine: tweak comment about current tags
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* tests/main/security-device-cgroup: tweak comments and messages
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* Revert "cmd: snap-confine does not need to link with libdl anymore"
This reverts commit 35d28c41d20d5f7d3451c4115041094db1f2ea4c.
* cmd/snap-confine: restore dlopen() to obtain udev_device_has_current_tag
Note that we could try to define udev_device_has_current_tag with a weak
attribute, which should in the normal case be the filled by ld.so when loading
snap-confined. However this was observed to work in practice only when the
binary itself is build with recent enough toolchain (eg. gcc & binutils on
Ubuntu 20.04). In case when the snapd snap needs to be built on 16.04, we have
observed that the weak symbol was indeed produced, but when resolving libraries
and symbols by ld.so on a recent host, the symbol would not be populated.
The patch revers to the original proposed behavior.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* tests/main/security-device-cgroups-serial-port: do not restart udev on 14.04
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
