linux-kernel - Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

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: <CALCETrU2tXM5sKx=L-K6=ARkvqefkcZHW3_RGhsgfc31FuWxJg@mail.gmail.com>
Date:	Mon, 17 Nov 2014 14:50:10 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"Eric W.Biederman" <ebiederm@...ssion.com>
Cc:	Casey Schaufler <casey@...aufler-ca.com>,
	Josh Triplett <josh@...htriplett.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>,
	Michael Kerrisk-manpages <mtk.manpages@...il.com>,
	Linux API <linux-api@...r.kernel.org>,
	linux-man <linux-man@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups
 to drop groups

On Mon, Nov 17, 2014 at 2:41 PM, Eric W.Biederman <ebiederm@...ssion.com> wrote:
>
>
> On November 17, 2014 1:46:59 PM EST, Andy Lutomirski <luto@...capital.net> wrote:
>>On Mon, Nov 17, 2014 at 10:31 AM, Andy Lutomirski <luto@...capital.net>
>>wrote:
>>> On Mon, Nov 17, 2014 at 10:06 AM, Casey Schaufler
>>> <casey@...aufler-ca.com> wrote:
>>>> On 11/15/2014 1:01 AM, Josh Triplett wrote:
>>>>> Currently, unprivileged processes (without CAP_SETGID) cannot call
>>>>> setgroups at all.  In particular, processes with a set of
>>supplementary
>>>>> groups cannot further drop permissions without obtaining elevated
>>>>> permissions first.
>>>>
>>>> Has anyone put any thought into how this will interact with
>>>> POSIX ACLs? I don't see that anywhere in the discussion.
>>>
>>> That means that user namespaces are a problem, too, and we need to
>>fix
>>> it.  Or we should add some control to turn unprivileged user
>>namespace
>>> creation on and off and document that turning it on defeats POSIX
>>ACLs
>>> with a group entry that is more restrictive than the other entry.
>>>
>>
>>This is a significant enough issue that I posted it to oss-security:
>>
>>http://www.openwall.com/lists/oss-security/2014/11/17/19
>>
>>It's not at all obvious to me how to fix it.  We could disallow userns
>>creation of any supplementary groups don't match fsuid, or we could
>>keep negative-only groups around in the userns.
>>
>>It may be worth adding a sysctl to change the behavior, too.  IMO it's
>>absurd to use groups to deny permissions that are otherwise available.
>
> There is an obvious user namespace fix.  Don't allow dropping supplemental groups that are not mapped.

Why exactly does this fix it?  I guess that, if a supplementary group
is in your subgid list, then we can assume that dropping it is safe?

>
> That will require a little bit of fancy footwork if you want to play with supplemental groups in your unprivileged user namespace.   I would like to get a grip on what hoops would be required before we add the additional restriction.  Possibly something as simple as calling sg.

The main hoop I can think of is that setgroups would be impossible to
call if you have an unmapped supplementary group.  This could break
all kinds of things.

>
> I also want to look at what Tizen and any other concrete pieces of code I can find using this negative permission pattern are actually doing.   Bugs definitely exist, but I have this erie feeling that the bugs may be in instances of userspace using this negative group permission pattern.  I think we may have a hideous case of one setuid binary defeating a privilege check of another piece of code.
>
> This issue looks like it is worth a full scale investigation.  Sigh.

Agreed.

>
> Eric



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/