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: <CAAbOScmsPice+1ttz=hQ4c+eGYR2jdaJxx_AM17rx_-=dnDjcw@mail.gmail.com>
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

Powered by blists - more mailing lists