linux-kernel - Re: [PATCH] groups: don't return unmapped gids in getgroups(2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Feb 2017 14:42:42 -0500
From:   Mike Frysinger <vapier@...omium.org>
To:     Aleksa Sarai <asarai@...e.de>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Linux API <linux-api@...r.kernel.org>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dev@...ncontainers.org, Aleksa Sarai <cyphar@...har.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [PATCH] groups: don't return unmapped gids in getgroups(2)

On Fri, Feb 17, 2017 at 12:53 PM, Aleksa Sarai wrote:
> >>>> One thing overlooked by commit 9cc46516ddf4 ("userns: Add a knob to
> >>>> disable setgroups on a per user namespace basis") is that because
> >>>> setgroups(2) no longer works in user namespaces it doesn't make any
> >>>> sense to be returning weird group IDs that the process cannot do
> >>>> anything with.
> >>>
> >>>
> >
> >> bool DropPrivileges()
> >> {
> >>         /* ... */
> >>       // Verify that the user isn't still in any supplementary groups
> >
> > But the user *is* still in a supplementary group.  Your proposed
> > change would break the intent of this code.
>
> I was about to say that "being in an unmapped supplementary group does
> not count as privileges", but decided to test it first and realised that
> this is not true? How is this not a blatant security vulnerability?

whether they're mapped is irrelevant.  if you make modifications to
the FS, the permission check counts against the meaning of the ids in
the parent namespaces.  otherwise your argument is like saying "i
mapped my UID to 0 in this new usernamespace, so how is that not a
blatant security vuln".

if you started out with access to the group, then keeping that access
doesn't grant you any new privs you didn't already have.

> % touch somefile
> % chmod 660 somefile
> % sudo chown root:wheel somefile
> % unshare -r
> % cat somefile
> % # no EACCES...

you didn't show `id` before the `unshare`.  if you're already in the
wheel group, what you've shown here is not a bug.
-mike