> Thanks for replying Eric, but I'm having trouble reproducing what you've
> posted. I can't write the gid map until I've written deny to
> /prod/$pid/setgroups, not the other way around. There might be some nuance
> I've missed.
Yes, this is a security feature. setgroups must be written to *before* gid_map
(the reason for this is explained further in user_namespaces(7)). And only
privileged users are allowed to write to gid_map if setgroups is set to allow.
> Also, newgidmap will allow a user to map their own GID to 0 in the user
> namespace, even when there is no entry for that user in /etc/subgid.
This is something that is generally required for a container to function, and
isn't fundamentally a security issue because users are already allowed to do
that without privileges (this is how rootless containers and LXC unprivileged
containers work) -- *unless* in this mode newgidmap is setting setgroups=allow
(in which case this is a major security problem).
> What if newgidmap wrote "deny" to /proc/$pid/setgroups unless the user is
> whitelisted in some config file, probably separate from /etc/subgid, as
> Stéphane suggested?
:+1: I'd prefer if we implemented this by changing the /etc/subgid schema so
that rather than having the format
user:id:id_cnt
It has the format
user:id:id_cnt[:flagA,flagB,...]
And we define flags "allow_setgroups" and "deny_setgrouops" (with
"deny_setgroups" being the default). This way, administrators can be *explicit*
about the denial, we don't add any new configuration files, and it's backwards
compatible (with security being opt-out).
I imagine making deny_setgroups might be a *bit* contentious, but in the worst
case we could have a migration script that asks users (or just add a document
about it to the logfile for the upgrade).
> Thanks for replying Eric, but I'm having trouble reproducing what you've pid/setgroups, not the other way around. There might be some nuance
> posted. I can't write the gid map until I've written deny to
> /prod/$
> I've missed.
Yes, this is a security feature. setgroups must be written to *before* gid_map (7)). And only
(the reason for this is explained further in user_namespaces
privileged users are allowed to write to gid_map if setgroups is set to allow.
> Also, newgidmap will allow a user to map their own GID to 0 in the user
> namespace, even when there is no entry for that user in /etc/subgid.
This is something that is generally required for a container to function, and
isn't fundamentally a security issue because users are already allowed to do
that without privileges (this is how rootless containers and LXC unprivileged
containers work) -- *unless* in this mode newgidmap is setting setgroups=allow
(in which case this is a major security problem).
> What if newgidmap wrote "deny" to /proc/$ pid/setgroups unless the user is
> whitelisted in some config file, probably separate from /etc/subgid, as
> Stéphane suggested?
:+1: I'd prefer if we implemented this by changing the /etc/subgid schema so
that rather than having the format
user:id:id_cnt
It has the format
user: id:id_cnt[ :flagA, flagB,. ..]
And we define flags "allow_setgroups" and "deny_setgrouops" (with
"deny_setgroups" being the default). This way, administrators can be *explicit*
about the denial, we don't add any new configuration files, and it's backwards
compatible (with security being opt-out).
I imagine making deny_setgroups might be a *bit* contentious, but in the worst
case we could have a migration script that asks users (or just add a document
about it to the logfile for the upgrade).