Security questions

LXD
#1

Hi, I have a few questions regarding security aspects of LXD.

  1. Do I understand it correctly that since the LXD daemon runs with root privileges on the host it does not matter which user is running the lxd/lxc commands? Or does it?
    Is there a difference security wise between running lxd init and all the lxc commands as root versus as user with sudo permissions versus a restricted user without sudo permissions and possibly even running a restricted shell (rbash)?

  2. On https://ubuntu.com/blog/custom-user-mappings-in-lxd-containers Stéphane writes about the downsides of per container maps: “It’s effectively impossible to share storage between two isolated containers as everything written by one will be seen as -1 by the other.”
    I don’t understand that. One could simply set up a host directory giving read and/or write permissions to the host UIDs the container UIDs map to using ACLs and bind mount them in the two containers with separated user mappings. Or would that not work for any reason? Even simpler, even though less secure, one could set up a shared host directory on the lines of /tmp which all containers could share irrespective of their UID/GID mappings. Or is there a catch I don’t see?

  3. What do you guys think of capsule8 and this article there: https://capsule8.com/blog/practical-container-escape-exercise/ ?

#2

Unprivileged containers in LXD are OK. LXD supports nice usability features that you can put on top of an unprivileged container. If you use them, you should be aware of potential risks. For example, you can share storage between a container and the host. By doing so, a malware in the container can create a trojan horse in the share storage, and you, as root on the host, may run it. For such cases, cue https://imgflip.com/memegenerator/39714036/Bike-Fall

The command lxc is a CLI client to control the LXD service. If a user on the host is member of the lxd group, then they can use lxc. LXD is so versatile so that if a user account is member of the lxd group, they should be considered they are administrators. Because, due to the versatility, there are many ways to become root on the host; so many that it is not worth it to put barriers. See, for example, https://shenaniganslabs.io/2019/05/21/LXD-LPE.html On the other hand, it is possible to add RBAC (role-based access control) to LXD so that a user can only do some of the tasks. But that feature has not free implementation yet.

On 2, the quote that you reference, talks about sharing storage between two containers. You then talk about sharing storage between the host and a container. LXD containers can be configured to have separate user maps from each other, and it makes sense that between the two, you cannot share storage as a device. Perhaps use some network service or something.

If you want to do some practice with LXD and isolated containers, have a look at https://blog.simos.info/a-network-isolated-container-in-lxd/ It’s a good practice to learn about proxy devices as well.

1 Like
#3

Some additions:

Point 2:
You can share storage volumes (documentation) between containers, but if you use isolated maps, you need shiftfs for that.

Simos is correct, currently it is only available with a Ubuntu Advantage subscription (Canonical RBAC service), see:
https://linuxcontainers.org/lxd/docs/master/security#role-based-access-control-rbac

I talked to @stgraber about it a while ago and he would like to have a free version for <5 systems for example.
So I guess talks about this are ongoing.
See comment in Github Issue.

1 Like