What are the security implications of adding the mappings echo 'root:1000:1' | sudo tee -a /etc/subuid /etc/subgid and lxc config set zesty raw.idmap 'both 1000 1000', beyond zesty having read/write access to paths that I’ve specifically mounted in it? For instance, I do not want the container user to have access to files owned by uid 1000 but outside of specifically mounted paths. I’m guessing there is a reason LXC/LXD doesn’t come with this mapping by default?
A container by default has some pretty good confinement, and what happens in the container, stays in the container.
For usability purposes though, you may poke holes in the container like doing what you described above.
That’s up to your use-care and requirement.
When you mount your home directory (or other directory) from the host to a container, then the container can only see that mount directory and any subdirectories only. That is, the container cannot escape the directory and peek into the parent directory.
If you are unsure as to how to use the container, you can describe your use-case.
For example, you might just require to have read-only access to the host’s home directory and so on.
My use case is to use the container to run an application under development, but use the editor/git/etc on my host OS. My hope is that I can simply not worry about security related to whatever dependencies the application has. In order to do this efficiently the project files (that I’m editing) need to be owned by my host OS user account, and the application itself may need to edit them too (unfortunately; actually now that I write this I realize trying to get rid of this requirement may be the way to go).
To talk more specifically about the mounting/mapping, I understand the general concept of mount points and the guest OS not being able to simply change the source of the mount to a different location. What I’m missing is exactly what extra permissions the suggested uid mappings give. My (possibly incorrect) understanding is that some of LXC’s security is derived by it not actually using the real root uid/user’s uid, and instead using subuids to run the container’s processes, and I further assumed that it can’t run processes or otherwise gain the privileges of the non-sub uid accounts. Does this mapping theoretically give the container the ability to run processes as uid 1000? Am I thinking about this wrong?
If your development environment is TUI (Text User Interface), that is, vim/emacs, etc, then you would easily put the whole development environment in a container.
If you wanted to separate the running application from your development environment, then you could have two containers, one of the development environment and another for the execution of the application. There are several network filesystems to use, and you are not restricted by id mapping and so on.
(still, you can do network filesystem sharing between the host and the container as well).