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  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:   Sat, 18 Feb 2017 04:53:59 +1100
From:   Aleksa Sarai <>
To:     Andy Lutomirski <>
Cc:     "Eric W. Biederman" <>,
        Andrew Morton <>,
        Alexey Dobriyan <>,
        "" <>,
        Aleksa Sarai <>,,
        Linux API <>,
        Linux Containers <>
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

Powered by blists - more mailing lists