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]

Message-ID: <6ab9118c-0476-99c8-cfbd-d3f5d378255e@suse.de>
Date:   Sat, 18 Feb 2017 04:53:59 +1100
From:   Aleksa Sarai <asarai@...e.de>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Aleksa Sarai <cyphar@...har.com>, dev@...ncontainers.org,
        Linux API <linux-api@...r.kernel.org>,
        Linux Containers <containers@...ts.linux-foundation.org>
Subject: Re: [PATCH] groups: don't return unmapped gids in getgroups(2)

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

I understand the `chmod 707` usecase and that being able to *block*
access is useful with supplementary groups, but I would _never_ have
guessed that *unmapped* supplementary groups *allow you to have access
to files*.

And not only would I have never guessed that to be the case, this makes
the fact that getgroups(2) returns 65534 even _more_ concerning -- how
on earth is a userspace process meant to know what secret privileges it
has? How can it make sane decisions about security with this setup?

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

Please someone tell me this is a regression and it's not meant to be
this way...

-- 
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/