Comment 12 for bug 1964636

We start seeing the same behavior in the Anbox Cloud CI for a few days now. What tests (via spread) primarily do:

1. ssh to an existing arm64 VM
2. Install a fresh LXD from latest/edge and configure it with the following preseed (setting security.nesting to true or false doesn't make a difference):

```
  config:
    cluster.https_address: $addr:8443
    core.https_address: $addr:8443
  cluster:
    enabled: false
    server_name: lxd0
  networks:
  - name: lxdbr0
    type: bridge
    config:
      ipv4.nat: true
      ipv4.dhcp.expiry: infinite
      ipv4.address: $LXD_SUBNET
      ipv6.address: none
  profiles:
  - name: default
    config:
      security.nesting: true
    devices:
      root:
        path: /
        pool: default
        type: disk
      eth0:
        type: nic
        nictype: bridged
        parent: lxdbr0
  storage_pools:
  - name: default
    driver: zfs
    config:
      size: 20GB
```

3. Now juju starts to bootstrap a controller on top of LXD and then we deploy our charms.
4. At some point the tests run the following:

11:08:00 ++++ timeout -s KILL 5m sudo -u root -H /snap/bin/juju ssh ams/0 -o 'ConnectionAttempts 30' -- /snap/bin/amc image add bionic:android10:arm64 /home/ubuntu/anbox-lxd-image.tar.xz
11:08:00 snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

This seems to be consis11:08:00 ++++ timeout -s KILL 5m sudo -u root -H /snap/bin/juju ssh ams/0 -o 'ConnectionAttempts 30' -- /snap/bin/amc image add bionic:android10:arm64 /home/ubuntu/anbox-lxd-image.tar.xz
11:08:00 snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

This doesn't always happen but I haven't yet checked if it's only happening on one particular machine. The VMs are all running 20.04