ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > >> On Tue, Dec 9, 2014 at 4:04 PM, Eric W.Biederman <ebiederm@xxxxxxxxxxxx> wrote: >>> >>> >>> On December 9, 2014 4:28:38 PM CST, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>>>On Tue, Dec 9, 2014 at 12:42 PM, Eric W. Biederman >>>><ebiederm@xxxxxxxxxxxx> wrote: >>>>> >>>>> - Expose the knob to user space through a proc file >>>>/proc/<pid>/setgroups >>>>> >>>>> A value of "deny" means the setgroups system call is disabled in >>>>the >>>>> current processes user namespace and can not be enabled in the >>>>> future in this user namespace. >>>>> >>>>> A value of "allow" means the segtoups system call is enabled. >>>>> >>>>> - Descendant user namespaces inherit the value of setgroups from >>>>> their parents. >>>>> >>>>> - A proc file is used (instead of a sysctl) as sysctls >>>>> currently do not pass in a struct file so file_ns_capable >>>>> is unusable. >>>> >>>>Reviewed-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx> >>>> >>>>But I still don't like the name "setgroups". People may look at that >>>>and have no clue what the scope of the setting is. And anyone who, as >>>>root, writes "deny" to /proc/self/setgroups, thinking that it acts on >>>>self, will be in for a surprise. >>> >>> True setgroups isn't perfect. Documenting it in a manpage may have to be enough. The only real improvement I can think of would be to make the setting a sysctl. But I think pursuing that approaches the point where perfection is the enemy of getting this problem fixed. >>> >> >> Would "userns_setgroups" be okay? > > Maybe. > > I just played with this and this is a much bigger booby trap than I had > realized. Disabling setgroups disables the possibility of logging in the > future and since it is a one way switch the only way out is to reboot. > > Hooray our software checks the returns of setgroups. Booh. This is a > really nasty knob to have anywhere. > > I need to think about this a little bit. Giving root the power to shoot > himself in the foot is one thing. Giving root a loaded gun pointed at > his foot with the hammer pulled back, and a sign that says I dare you to > pull the trigger, seems like a bad idea. > > I think I need to reduce when that knob can be used. Grr. > Back to the drawing board! I tried out a bunch of things and finally found a simple rule. Don't allow setgroups to be disabled after setgroups has been enabled in a user namespace. Or in practical terms don't allow setgroups to be disabled after the gid_map has been set. Which in practice pretty nearly means that we are only allowing writes to setgroups when it is a single process and it's eventual children that can be affected. At which point I don't think a name change would make things any clearer. I have also updated the code to move the permission checks to open where they belong (doh!). Patch follows. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
