From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752716AbbBXPrT (ORCPT ); Tue, 24 Feb 2015 10:47:19 -0500 Received: from h2.hallyn.com ([78.46.35.8]:49398 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750748AbbBXPrR (ORCPT ); Tue, 24 Feb 2015 10:47:17 -0500 Date: Tue, 24 Feb 2015 09:47:15 -0600 From: "Serge E. Hallyn" To: "Serge E. Hallyn" Cc: Serge Hallyn , Christoph Lameter , Serge Hallyn , Andy Lutomirski , Aaron Jones , "Ted Ts'o" , linux-security-module@vger.kernel.org, akpm@linuxfoundation.org, "Andrew G. Morgan" , Mimi Zohar , Austin S Hemmelgarn , Markku Savela , Jarkko Sakkinen , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Michael Kerrisk , Jonathan Corbet Subject: Re: [PATCH] capabilities: Ambient capability set V1 Message-ID: <20150224154715.GA20682@mail.hallyn.com> References: <20150223161625.GD25477@ubuntumail> <20150223164623.GB32181@mail.hallyn.com> <20150223181553.GE25477@ubuntumail> <20150224051928.GA14755@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150224051928.GA14755@mail.hallyn.com> 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 On Mon, Feb 23, 2015 at 11:19:29PM -0600, Serge E. Hallyn wrote: > On Mon, Feb 23, 2015 at 06:15:53PM +0000, Serge Hallyn wrote: > > Quoting Christoph Lameter (cl@linux.com): > > > On Mon, 23 Feb 2015, Serge E. Hallyn wrote: > > > > > > > > I do not see a problem with dropping privilege since the ambient set > > > > > is supposed to be preserved across a drop of priviledge. > > > > > > > > Because you're tricking the program into thinking it has dropped > > > > the privilege, when in fact it has not. > > > > > > So the cap was dropped from the cap perm set but it is still active > > > in the ambient set? > > > > Right, and the legacy program doesn't know to check the new set. > > we've been assuming the ambient set must be like fP. is there any > reason why it doesn't suffice for them to be or'ed with fI instead at > exec? then the bits would need to ne in pI. this might sufice for > Christoph's use case, as pI will generally not change. and for programs > that really care, they can check pI. The other way to look at it then is that it's basically as though the privileged task (which has CAP_SETFCAP) could've just added fI=full to all binaries on the filesystem; instead it's using the ambient set so that the risk from fI=full is contained to its own process tree. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [PATCH] capabilities: Ambient capability set V1 Date: Tue, 24 Feb 2015 09:47:15 -0600 Message-ID: <20150224154715.GA20682@mail.hallyn.com> References: <20150223161625.GD25477@ubuntumail> <20150223164623.GB32181@mail.hallyn.com> <20150223181553.GE25477@ubuntumail> <20150224051928.GA14755@mail.hallyn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20150224051928.GA14755-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Serge E. Hallyn" Cc: Serge Hallyn , Christoph Lameter , Serge Hallyn , Andy Lutomirski , Aaron Jones , Ted Ts'o , linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, "Andrew G. Morgan" , Mimi Zohar , Austin S Hemmelgarn , Markku Savela , Jarkko Sakkinen , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Michael Kerrisk , Jonathan Corbet List-Id: linux-api@vger.kernel.org On Mon, Feb 23, 2015 at 11:19:29PM -0600, Serge E. Hallyn wrote: > On Mon, Feb 23, 2015 at 06:15:53PM +0000, Serge Hallyn wrote: > > Quoting Christoph Lameter (cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org): > > > On Mon, 23 Feb 2015, Serge E. Hallyn wrote: > > > > > > > > I do not see a problem with dropping privilege since the ambient set > > > > > is supposed to be preserved across a drop of priviledge. > > > > > > > > Because you're tricking the program into thinking it has dropped > > > > the privilege, when in fact it has not. > > > > > > So the cap was dropped from the cap perm set but it is still active > > > in the ambient set? > > > > Right, and the legacy program doesn't know to check the new set. > > we've been assuming the ambient set must be like fP. is there any > reason why it doesn't suffice for them to be or'ed with fI instead at > exec? then the bits would need to ne in pI. this might sufice for > Christoph's use case, as pI will generally not change. and for programs > that really care, they can check pI. The other way to look at it then is that it's basically as though the privileged task (which has CAP_SETFCAP) could've just added fI=full to all binaries on the filesystem; instead it's using the ambient set so that the risk from fI=full is contained to its own process tree.