The trouble with dropping groups

Posted Nov 20, 2014 1:38 UTC (Thu) by skissane (subscriber, #38675)
Parent article: The trouble with dropping groups

What about a flag on a group which says it is allowed to be dropped by an unprivileged process? By default, that flag would not be enabled for any group, but sysadmin could enable it on a group-by-group basis. That would likely be much safer than an across-the-board sysctl knob.

to post comments

The trouble with dropping groups

Posted Nov 20, 2014 5:21 UTC (Thu) by ncm (guest, #165) [Link] (5 responses)

I had the same thought, immediately. There must be something wrong with it if everybody on the kernel list didn't also post it simultaneously, but I am evidently too ignorant to guess what the flaw is. Would anyone care to enlighten us?

The trouble with dropping groups

Posted Nov 20, 2014 6:50 UTC (Thu) by luto (subscriber, #39314) [Link] (4 responses)

Groups are just numbers -- they have no flags. I did suggest a sysctl to specify groups that are safe to drop, but that's tedious and ugly.

The trouble with dropping groups

Posted Nov 20, 2014 7:45 UTC (Thu) by neilbrown (subscriber, #359) [Link]

A sysctl which identified a range of groups that could be dropped wouldn't be too tedious.

Then it would only be logical to also identify a range of groups that could freely be added - if the goal is to lose privileges, and adding groups achieves that, then maybe it should be allowed.

Having observed that, it starts to feel very much like the wrong solution to the problem.

The trouble with dropping groups

Posted Nov 20, 2014 21:26 UTC (Thu) by skissane (subscriber, #38675) [Link] (2 responses)

How about modifying struct group_info to add a flags word for each supplementary group? One bit of the flags word would be used to indicate if the supplementary group is droppable by unprivileged callers, the others would be reserved for future use. Add new setgroups2() system call which allows privileged processes to set the flags words when the groups are set, and allow getgroups2() to allow unprivileged callers to retrieve both the groups and the associated flags.

The trouble with dropping groups

Posted Nov 20, 2014 21:37 UTC (Thu) by luto (subscriber, #39314) [Link] (1 responses)

The problem with that is that existing userspace won't understand it at all. Without something clever, one side effect is likely to be that it will completely disable unprivileged user namespaces on most systems.

The trouble with dropping groups

Posted Nov 21, 2014 0:48 UTC (Fri) by skissane (subscriber, #38675) [Link]

I would expect that setgroups() / getgroups() would still work, setgroups() would just zero the flags words. (Alternatively, if we call setgroups() with an already present group, it could leave the flags word for that group unchanged.) So yes, for this to be usable, privileged userspace code which calls setgroups() would need to be modified to call setgroups2(). Without that change, existing userspace code should still work, it just wouldn't be able to access the droppable groups feature. In order to use the droppable groups feature, you'd need to update user space code which calls setgroups() to call setgroups2() instead with the desired flags word (reading it from NSS groups database I presume). [Of course, setgroups2() should fail if an attempt is made to set a reserved bit to a non-zero value.]