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
Subject: Re: [RFC PATCH 0/3] new mode 'shadow' for /proc/PID/setgroups
Date: Fri, 21 May 2021 10:16:43 -0500 [thread overview]
Message-ID: <m1o8d4xgkk.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20210510130011.1441834-1-gscrivan@redhat.com> (Giuseppe Scrivano's message of "Mon, 10 May 2021 15:00:08 +0200")
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
next prev parent reply other threads:[~2021-05-21 15:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 13:00 Giuseppe Scrivano
2021-05-10 13:00 ` [RFC PATCH 1/3] setgroups: " Giuseppe Scrivano
2021-05-15 1:51 ` Serge E. Hallyn
2021-05-17 13:30 ` Giuseppe Scrivano
2021-05-17 14:33 ` Christian Brauner
2021-05-17 16:17 ` Serge E. Hallyn
2021-05-18 9:32 ` Christian Brauner
2021-05-17 19:00 ` Giuseppe Scrivano
2021-05-18 9:16 ` Christian Brauner
2021-05-21 14:03 ` Snaipe
2021-05-17 16:08 ` Serge E. Hallyn
2021-05-10 13:00 ` [RFC PATCH 2/3] getgroups: hide unknown groups Giuseppe Scrivano
2021-05-15 1:21 ` Serge E. Hallyn
2021-05-10 13:00 ` [RFC PATCH 3/3] proc: hide unknown groups in status Giuseppe Scrivano
2021-05-15 1:24 ` Serge E. Hallyn
2021-05-10 16:02 ` [RFC PATCH 0/3] new mode 'shadow' for /proc/PID/setgroups Snaipe
2021-05-21 15:16 ` Eric W. Biederman [this message]
2021-05-24 13:41 ` Giuseppe Scrivano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1o8d4xgkk.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=christian.brauner@ubuntu.com \
--cc=dwalsh@redhat.com \
--cc=gscrivan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®