Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   ebiederm@xmission.com (Eric W. Biederman)
To:     Giuseppe Scrivano <gscrivan@redhat.com>
Cc:     linux-kernel@vger.kernel.org, serge@hallyn.com, dwalsh@redhat.com,
        christian.brauner@ubuntu.com
References: <20210510130011.1441834-1-gscrivan@redhat.com>
Date:   Fri, 21 May 2021 10:16:43 -0500
In-Reply-To: <20210510130011.1441834-1-gscrivan@redhat.com> (Giuseppe
        Scrivano's message of "Mon, 10 May 2021 15:00:08 +0200")
Message-ID: <m1o8d4xgkk.fsf@fess.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [RFC PATCH 0/3] new mode 'shadow' for /proc/PID/setgroups
Precedence: bulk

Giuseppe Scrivano <gscrivan@redhat.com> writes:

> This series is based on some old patches I've been playing with some
> years ago, but they were never sent to lkml as I was not sure about
> their complexity/usefulness ratio.  It was recently reported by
> another user that these patches are still useful[1] so I am submitting
> the last version and see what other folks think about this feature.
>
> Since the fix for CVE-2014-8989 in order to set a gids mapping for a
> user namespace when the user namespace owner doesn't have CAP_SETGID
> in its parent, it is necessary to first disable setgroups(2) through
> /proc/PID/setgroups.
>
> Setting up a user namespace with multiple IDs mapped into is usually
> done through the privileged helpers newuidmap/newgidmap.
> Since these helpers run either as setuid or with CAP_SET[U,G]ID file
> capabilities, it is not necessary to disable setgroups(2) in the
> created user namespace.  The user running in the user namespace can
> use setgroups(2) and drop the additional groups that it had initially.
>
> This is still an issue on systems where negative groups ACLs, i.e. the
> group permissions are more restrictive than the entry for the other
> categories, are used.  With such configuration, allowing setgroups(2)
> would cause the same security vulnerability described by
> CVE-2014-8989.

Do you have any experience or any documentation about systems that are
using groups to deny access?

There are some deployments somewhere, but last I looked they were rare
enough that the intersection between systems using groups to deny access
and systems deploying containers could reasonably be assumed to be the
empty set?

Before we seriously consider merging a change like this I believe we
need some references to actual deployed systems.  As adding a feature
that is designed around a premise of a security model that people
are not using will likely lead to poor testing, poor review and
not enough feedback to get the rough edges off.


I suspect systems need to preserve some set of groups released from
the restriction of needing to preserve negative groups could result
in a very different result.

Eric