This should ensure that any older versions of snapd that are vulnerable to this
new CVE-2022-3328 are uninstalled on upgrade to the fixed version.
Signed-off-by: Alex Murray <alex.murray@canonical.com>
The output format of ls could vary depending on the local systems locale etc whereas
the output of stat is fixed so use this instead to check file owner /
permissions.
Signed-off-by: Alex Murray <alex.murray@canonical.com>
To avoid unprivileged users being able to interfere with the creation of the
private snap mount namespace, instead of creating this as /tmp/snap.$SNAP_NAME/
we can now use the systemd-tmpfiles configuration to do this for us
at boot with a known fixed name (/tmp/snap-private-tmp/) and then use that as
the base dir for creating per-snap private tmp mount
namespaces (eg. /tmp/snap-private-tmp/snap.$SNAP_INSTANCE/tmp) etc.
Signed-off-by: Alex Murray <alex.murray@canonical.com>
Use systemd-tmpfiles to create the private tmp mount namespace root
dir (/tmp/snap-private-tmp) on boot as owned by root with restrictive
permissions. We can use this as a known location to then create per-snap
private tmp mount namespace dirs (/tmp/snap-private-tmp/snap.$SNAP_INSTANCE)
etc.
Signed-off-by: Alex Murray <alex.murray@canonical.com>
Some customizations (cloud init configuration seeding, disabling of
console conf) were not happening for UC16/18 if there were also
defaults in the gadget. This fixes an early return that was the
cause (LP: #1997494).
Thanks to Alberto Mardegan for test suggestion.
GCC 12.2.1 with the default build flags in Rawhide is more picky than usual, and
fails with this:
snap-confine/selinux-support.c:85:29: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
85 | char *new_ctx_str = context_str(ctx);
| ^~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Maciej Borzecki <maciek.borzecki@gmail.com>
Currently snaps that use python3.10 from core22 will fail on older
releases of ubuntu:
```
$ sudo snap install test-snapd-sh-core22
$ test-snapd-sh-core22.sh -c 'python3 -c "import ssl"'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3.10/ssl.py", line 98, in <module>
import _ssl # if we can't import it, let the error propagate
ImportError: /usr/lib/python3.10/lib-dynload/_ssl.cpython-310-x86_64-linux-gnu.so: failed to map segment from shared object
```
It turns out our apparmor template only allows:
```
/usr/lib{,32,64}/python3.[0-9]/lib-dynload/*.so mr,
```
so anything beyond `python3.9` will not work. This commit adds a
regression test and allows for `/python3.[0-9]*/` to fix the
issue.
Wayland clients share memory with the compositor by creating a file
descriptor, and passing it to the server via an SCM_RIGHTS message. Both
sides then mmap the fd. For GTK and Qt apps, this doesn't require any
additional permissions because they create the fd with memfd_create(),
which has no file system path.
Unfortunately Firefox's Wayland code uses shm_open(), which creates a
file system backed file. The compositor will only be able to use the fd
it receives if it's AppArmor profile allows access to that file. So we
need a rule granting access to the path it uses.
Since Current sometimes differed from PinnedAt even when PinnedAt != 0,
be more robust by using a Sequence() method that takes PinnedAt into
account when reading as well.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
Make sure that the current sequence number in the validation set
tracking is set to the same as the pinned sequence number, if the
validation set is pinned (PinnedAt != 0).
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
The test is failing with a non critical AppArmor error message, but the
real failure is due to QEMU command-line parsing:
error: internal error: qemu unexpectedly closed the monitor:
2022-10-03T11:56:15.932697Z qemu-system-x86_64:
-device {"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.0","addr":"0x2"}:
PCI: slot 2 function 0 not available for virtio-balloon-pci, in use by virtio-net-pci,id=(null)
This happens because something in libvirt (or maybe QEMU itself) adds an
implicit PCI device on address 0x2 -- the log line pasted above shows
what device is being added. This bug has also been noticed by other
projects, see comment 45 on https://bugzilla.redhat.com/show_bug.cgi?id=2034160
The workaround we use is to specify a virtio-net-pci device on another
PCI address, in order to avoid the address conflict.
