From mboxrd@z Thu Jan 1 00:00:00 1970 From: josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org Subject: Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups Date: Mon, 17 Nov 2014 14:37:30 -0800 Message-ID: <20141117223730.GA961@cloud> References: <20141115202042.GA20900@thin> <20141116020511.GB5507@thunk.org> <6C690A2C-8EB1-421A-94C3-9803AFB95760@joshtriplett.org> <20141116034005.GC5507@thunk.org> <20141116045232.GB18880@thin> <20141117113734.396798e6@lxorguk.ukuu.org.uk> <0b65fd07-48ea-483b-8fd5-fd84d0bff881@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Lutomirski Cc: "Eric W.Biederman" , One Thousand Gnomes , linux-man , Ted Ts'o , Michael Kerrisk-manpages , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Andrew Morton , Linux API , Kees Cook List-Id: linux-api@vger.kernel.org On Mon, Nov 17, 2014 at 02:22:59PM -0800, Andy Lutomirski wrote: > On Mon, Nov 17, 2014 at 2:11 PM, Eric W.Biederman wrote: > > > > > > On November 17, 2014 1:07:30 PM EST, Andy Lutomirski wrote: > >>On Nov 17, 2014 3:37 AM, "One Thousand Gnomes" > >> wrote: > >>> > >>> > optional), I can do that too. The security model of "having a > >>group > >>> > gives you less privilege than not having it" seems crazy, but > >>> > nonetheless I can see a couple of easy ways that we can avoid > >>breaking > >>> > >>> It's an old pattern of use that makes complete sense in a traditional > >>> Unix permission world because it's the only way to do "exclude > >>{list}" > >>> nicely. Our default IMHO shouldn't break this. > >>> > >>> > that pattern, no_new_privs being one of them. I'd like to make > >>sure > >>> > that nobody sees any other real-world corner case that unprivileged > >>> > setgroups would break. > >>> > >>> Barring the usual risk of people doing improper error checking I > >>don't > >>> see one immediately. > >>> > >>> For containers I think it actually makes sense that the sysctl can be > >>> applied per container anyway. > >> > >>We'll probably need per container sysctls some day. > > > > We already have a mess of per network namespace sysctls, > > as well as few for other namespaces. > > > > We have the infrastructure it is just a matter of using it for whatever purpose we need. > > > > A list of group id ranges that it's permissible to drop would do the > trick, both for setgroups and for unshare. The downside would be that > users in those groups (i.e. everyone by default) would not be able to > unshare their user ns. > > Better ideas welcome. Personally, I think that seems like more flexibility than necessary to achieve the goal. I think a sysctl turning group-dropping on and off would suffice; systems that know they don't use groups to exclude specific users can enable that sysctl. - Josh Triplett