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

On Thu, Dec 11, 2014 at 5:09 PM, Eric W. Biederman
[off-list ref] wrote:

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

quoted

Andy Lutomirski [off-list ref] writes:

quoted

On Tue, Dec 9, 2014 at 4:04 PM, Eric W.Biederman [off-list ref] wrote:

quoted

On December 9, 2014 4:28:38 PM CST, Andy Lutomirski [off-list ref] wrote:

quoted

On Tue, Dec 9, 2014 at 12:42 PM, Eric W. Biederman
[off-list ref] wrote:

quoted

- Expose the knob to user space through a proc file

/proc/<pid>/setgroups

quoted

  A value of "deny" means the setgroups system call is disabled in

the

quoted

  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 <redacted>

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