Linux Privilege Escalation via LXD & Hijacked UNIX Socket Credentials

Here is an interesting post by Shenanigans Labs,

When we setup LXD, we create a non-root account and add it to the lxd group.
By doing so, we can run any lxc command without having to prepend sudo to it.
The benefit is that we can manage LXD without being logged in as root.
But should we extend this idea in order to make an unprivileged user the administrator of LXD?

The post describes how an account on the host that is member of the lxd group (therefore, can manage LXD), is able to become root on the host by taking advantage of features in LXD.
In this specific case, they use the proxy device functionality to proxy Unix sockets, which makes it possible to get systemd on the host to run our commands and thus become root.

How should this be resolved? Should the LXD proxy device be configured so that you need sudo if you want to create a Unix socket proxy device?
Should the LXD proxy device blacklist some commands?

LXD is becoming feature-rich, and if it is not for proxy device on Unix socket, in the future there will be some other feature that can give root access to the host (for the non-root account that is member of lxd).

Adding workarounds to fix specific cases (like here with the proxy device) is likely bad software design.

LXD now supports Role-Based Access Control (RBAC), which means that you can apply a role to the non-root account that manages LXD. There are predefined roles, like auditor that can only view the container information, and user that can perform normal life-cycle tasks. I am not sure if the user role can create proxy devices. If they cannot, then that could be a workaround for now.

Having said all that, in many cases, the non-root account that manages LXD (thus, member of the lxd group) is also member of the sudo group. In such a setup, this privilege escalation issue is not relevant because the user can become root directly by running sudo.

From what I have seen at the bug report on this, the direction is that being a member of the lxd group to administer LXD, makes you still a privileged user and such accounts should be considered as such (i.e. sudo).
That is, it is not advised to consider that the non-root LXD administration account is a really unprivileged account.
RBAC could help here, though you need to enable Landscape to use it.