Re: [CFT][PATCH 7/8] userns: Add a knob to disable setgroups on a per user namespace basis

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) writes:

> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>
>> On Tue, Dec 9, 2014 at 4:04 PM, Eric W.Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>
>>>
>>> On December 9, 2014 4:28:38 PM CST, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>>>>On Tue, Dec 9, 2014 at 12:42 PM, Eric W. Biederman
>>>><ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> 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-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
>>>>
>>>>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