[lxc-users] Is an unprivileged LXC where the host user itself is mapped to 0 less secure of one where one of its subids is mapped to 0, and why?

Fajar A. Nugraha list at fajar.net
Tue Oct 6 02:26:59 UTC 2015

On Mon, Oct 5, 2015 at 11:58 PM, Fabio Tudone
(fabio at paralleluniverse.co) <fabio at paralleluniverse.co> wrote:
> On 09/30/2015 08:38 PM, Serge Hallyn wrote:
>>> On a more practical level what could be the security implications?
>>> Are there host resources that a malicious program could compromise
>>> when running in a container with the capabilities of a regular host
>>> user mapped in there? Even because of (hypothetical) system issues /
>>> bugs / vulnerabilities. Can someone think of actual examples?
>> yes.
> Could you expand on that? What could happen for example? I'm no security
> expert but I'm interested in understanding the implications.

I believe the simplest example would probably be from Stephane's blog:
https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/ . User
1000 in the host is mapped to the same uid on the container, for the
purpose of easy configuration of X and sound access from the

Should some security vulnerability occur that allows the user to
escape the container (or run arbitrary command inside the host), the
"escaped" user will be restricted as uid 1000, which is theoretically
still much safer compared to privileged container.

However even that non-root-on-the-host user might still cause problems:
- If you have assigned additinal permission for that user (e.g. If uid
1000 on the host is a member of "disk" group, which has write access
to block devices), the user can wreak havoc using that additional
- If that user has created several containers, the "escaped" user can
compromise other containers belong to that user

So short version:
- much safer than privileged container
- can potentially still cause problems as that uid
- use different id_map (with uids not used on the host) for each
container if you want maximum security


More information about the lxc-users mailing list