GHSA-56mx-8g9f-5crf

Incus vulnerable to local privilege escalation through custom storage volumes

### Impact This affects any Incus user in an environment where an unprivileged user may have root access to a container with an attached custom storage volume that has the `security.shifted` property set to `true` as well as access to the host as an unprivileged user. The most common case for this would be systems using `incus-user` with the less privileged `incus` group to provide unprivileged users with an isolated restricted access to Incus. Such users may be able to create a custom storage volume with the necessary property (depending on kernel and filesystem support) and can then write a setuid binary from within the container which can be executed as an unpriivleged user on the host to gain root privileges. ### Patches A patch for this issue is available here: https://github.com/lxc/incus/pull/2642 The first commit changes the permissions for any new storage pool, the second commit applies it on startup to all existing storage pools. ### Workarounds Permissions can be manually restricted until a patched version of Incus is deployed. This is done with: ``` chmod 0700 /var/lib/incus/storage-pools/*/* chmod 0711 /var/lib/incus/storage-pools/*/buckets* chmod 0711 /var/lib/incus/storage-pools/*/container* ``` Those are the same permissions which will be applied by the patched Incus for both new and existing storage pools. ### References This was reported publicly on Github by here: https://github.com/lxc/incus/issues/2641