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

[Andy Lutomirski]

On Thu, Dec 11, 2014 at 5:09 PM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
> 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.

The name change still helps the user to does:

$ ls /proc/self

"setgroups?  what's that?"

>
> I have also updated the code to move the permission checks to open
> where they belong (doh!).  Patch follows.

Will review and test.

>
> Eric
>
>
>
>
>
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/