lxd: Introduce identity mapped privileged containers

[brauner]

Some time ago I proposed the concept of a "semi-privileged" or "capability-isolated" container something I've mentioned on the kernel list as a potential use-case for identity mappings and why v3 fscaps that are valid in an ancestor userns need to be supported. I pitched this idea to Lennart who duly implemented this as part of his adoption of my idmapped mount kernel work (cf. systemd/systemd@33eac55 .

The advantage of this is that you get a privileged container wrt to {fs,e,s}{uid,gid} while being capability isolated from the host. This is a rather useful concept as it provides users with purely id-based privileges while isolating capability-based privileges (Which are nowadays more hurtful.). I would propose we adopt this in LXD making use of a new config option.

If this sounds like something that is useful to support we need to settle on the semantics. There are a few ways to go:

• security.privileged gets converted from a boolean to a string and takes an additional value e.g. "capability-isolated" or something nicer.
  "false" and "true" would obviously still be recognized as usual. This should work and we could probably simply advance our "security.privileged" based codepaths to also handle "capability-isolated", i.e. treat "capability-isolated" like an unprivileged container.
  To create such a capability-isolated container we would still require that the project or the daemon is not run in unprivileged-only mode.
• Introduce a new subkey security.privileged.idmap (or a better name). If we do that we need kinda imply that it can be used as an extension to security.privileged which is not completely true.
• Introduce a new subkey security.capability_isolated (or a better name). This key we could either combine or not combine with security.privileged.
• Can the concept and don't use it (/me frowns :)).

[stgraber]

Ok, so just to get this right, it's:

• Using a user namespace but with the full host uid/gid map written as subuid/subgid
• This causes normal userns resource ownership to still work with all capabilities tied to the userns
• Filesystem just works because there's no shift needed

And all we'd really need to do here is set lxd.idmap to the full user/group range?

If so, I think that's fine and can be useful to some as a slightly safer privileged container. security.privileged taking an extra value is fine with me.

[brauner]

Ok, so just to get this right, it's:

• Using a user namespace but with the full host uid/gid map written as subuid/subgid
• This causes normal userns resource ownership to still work with all capabilities tied to the userns
• Filesystem just works because there's no shift needed

And all we'd really need to do here is set lxd.idmap to the full user/group range?

Yep!

If so, I think that's fine and can be useful to some as a slightly safer privileged container. security.privileged taking an extra value is fine with me.

Cool!