GHSA-56mx-8g9f-5crf
Incus vulnerable to local privilege escalation through custom storage volumes
Packages
| Ecosystem | Package | Affected | Fixed in |
|---|---|---|---|
| Go | github.com/lxc/incus/v6 | < 6.19.0 | 6.19.0 |
Details
As written in the advisory (Markdown source, shown as plain text).
### 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
References
External links from the advisory. They lead to third-party sites.