From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups Date: Mon, 17 Nov 2014 14:50:10 -0800 Message-ID: References: <3ccec8a13019b5e8ce7b1d7889677b778b070dc8.1416041823.git.josh@joshtriplett.org> <0895c1f268bc0b01cc6c8ed4607d7c3953f49728.1416041823.git.josh@joshtriplett.org> <546A3942.5040906@schaufler-ca.com> <9f43a787-165e-4256-a097-f7691204d9d6@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <9f43a787-165e-4256-a097-f7691204d9d6-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org> Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Eric W.Biederman" Cc: Casey Schaufler , Josh Triplett , Andrew Morton , Kees Cook , Michael Kerrisk-manpages , Linux API , linux-man , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-api@vger.kernel.org On Mon, Nov 17, 2014 at 2:41 PM, Eric W.Biederman wrote: > > > On November 17, 2014 1:46:59 PM EST, Andy Lutomirski wrote: >>On Mon, Nov 17, 2014 at 10:31 AM, Andy Lutomirski >>wrote: >>> On Mon, Nov 17, 2014 at 10:06 AM, Casey Schaufler >>> 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-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html