For upgrades from versions that are lower than 2.45.2 we need to
restart "snap userd" to ensure that we have the new version
running after the upgrade.
tests/main/cloud-init: on UC16 and UC18 ensure that cloud-init was restricted
Here, we are relying on cloud-init being used by the backend (namely google
here), and testing that snapd wrote cloud-init configuration out to restrict
cloud-init.
tests/nested/manual: add test for cloud-init vuln when NoCloud was used
This test exercises 2 cases on UC16 and UC18 related to CVE-2020-11933 where
devices already have used the NoCloud cloud-init datasource:
* A device in the field without the snapd CVE fix is not vulnerable after
getting the fix
* New devices with images build with the snapd CVE fix are not vulnerable
tests/nested/manual: add test for cloud-init vuln when cloud-init was never used
This test exercises 2 cases on UC16 and UC18 related to CVE-2020-11933:
* A device in the field without the snapd CVE fix is not vulnerable after
getting the fix
* New devices with images build with the snapd CVE fix are not vulnerable
The execution is a bit confusing, as we have to force stop the VM systemd unit,
then "re-run" it with different arguments with PARAM_CD, eventually it would be
nice if there was a better way to modify the arguments to QEMU for the VM unit,
but this is good enough for now and demonstrates the fix is effective.
tests/lib/nested.sh: allow specifying a cdrom drive opts
This will allow for cloud-init testing where we will craft external NoCloud
cloud-init datasources that show up as cdrom drives and provide them to the VM.
tests/lib/nested.sh: split out start_nested_core_vm into helper funcs
We now are able to create/start a nested VM with start_nested_core_vm, then stop
it with force_stop_nested_vm which stops the systemd unit for running QEMU, and
then re-start the VM with different arguments using start_nested_core_vm_unit
without running into issues like prepare_ssh failing to run twice because the
test user is already there, or deleting/recreating the VM disk image file, etc.
We also block waiting for the systemd unit to become active, because if we have
a catastrophic failure in running qemu in the systemd unit, we don't want to
wait for SSH to become available because it never will, so this will make the
logs more obvious that the nested-vm systemd unit is down.
tests/lib/snaps.sh: add functions to build core and snapd snaps from deb
These are similar to the existing functions in prepare.sh, but they are more
specific in that they download a fresh copy of the snaps in question, and are
meant to be used temporarily until we can sort out how to combine the two
implementations because prepare.sh is doing a bit more than we need here.
