Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752960AbbBWQqA (ORCPT ); Mon, 23 Feb 2015 11:46:00 -0500 Received: from h2.hallyn.com ([78.46.35.8]:56713 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752474AbbBWQp6 (ORCPT ); Mon, 23 Feb 2015 11:45:58 -0500 Date: Mon, 23 Feb 2015 10:45:57 -0600 From: "Serge E. Hallyn" To: Andy Lutomirski Cc: Serge Hallyn , Christoph Lameter , Serge Hallyn , Aaron Jones , "Ted Ts'o" , LSM List , Andrew Morton , "Andrew G. Morgan" , Mimi Zohar , Austin S Hemmelgarn , Markku Savela , Jarkko Sakkinen , "linux-kernel@vger.kernel.org" , Linux API , Michael Kerrisk , Jonathan Corbet Subject: Re: [PATCH] capabilities: Ambient capability set V1 Message-ID: <20150223164557.GA32181@mail.hallyn.com> References: <20150223161625.GD25477@ubuntumail> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2354 Lines: 53 On Mon, Feb 23, 2015 at 08:33:58AM -0800, Andy Lutomirski wrote: > On Mon, Feb 23, 2015 at 8:16 AM, Serge Hallyn wrote: > > Quoting Christoph Lameter (cl@linux.com): > >> Ok 4.0-rc1 is out and this patch has been sitting here for a couple of > >> weeks without comment after an intensive discussion about the RFCs. > >> > >> Since there were no objections: Is there any chance to get this into -next > >> somehow? > > > > Andrew Morgan and Andy Lutomirski appear to have a similar concern > > but competing ideas on how to address them. We need them to agree > > on an approach. > > > > The core concern for amorgan is that an unprivileged user not be > > able to cause a privileged program to run in a way that it fails to > > drop privilege before running unprivileged-user-provided code. > > > > Andy Lutomirski's concern is simply that code which is currently > > doing the right thing to drop privilege not be run in a way that > > it thinks it is dropping privilege, but in fact is not. > > > > I share both concerns. > > > (Please correct me where I've mis-spoken or misunderstood) > > > > Since your desire is precisely for a mode where dropping privilege > > works as usual, but exec then re-gains some or all of that privilege, > > we need to either agree on a way to enter that mode that ordinary > > use caes can't be tricked into using, or find a way for legacy > > users to be tpiped off as to what's going on (without having to be > > re-written) > > Is there really a need to drop privilege and then regain it or is it > sufficient to keep the privilege permitted (and perhaps ambient, too) > and just to have execve not drop it for you? I assume the latter. Well right, any perceived security benefit of the temporary drop would seem to be easily debunked (just run shell for exec /bin/sh to get around it) So this is more of a desire, I suspect, for regular programs which drop privilege to still be usable in this environment. I think this may be a decent place for a compromise. Attempts to drop privilege when ambient caps are set return EPERM. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/