From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752716AbbBWQog (ORCPT ); Mon, 23 Feb 2015 11:44:36 -0500 Received: from resqmta-ch2-11v.sys.comcast.net ([69.252.207.43]:52775 "EHLO resqmta-ch2-11v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751948AbbBWQoe (ORCPT ); Mon, 23 Feb 2015 11:44:34 -0500 Date: Mon, 23 Feb 2015 10:44:32 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Serge Hallyn cc: 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 In-Reply-To: <20150223161625.GD25477@ubuntumail> Message-ID: References: <20150223161625.GD25477@ubuntumail> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 23 Feb 2015, Serge Hallyn wrote: > 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. I do not see a problem with dropping privilege since the ambient set is supposed to be preserved across a drop of priviledge. > 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, I would say that the ambient set stays active even if the setuid binary drops to regular perms. > 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) Well if the ambient set is completely separate then the existing semantics are preserved while the ambient set stays active as intended. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Lameter Subject: Re: [PATCH] capabilities: Ambient capability set V1 Date: Mon, 23 Feb 2015 10:44:32 -0600 (CST) Message-ID: References: <20150223161625.GD25477@ubuntumail> Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <20150223161625.GD25477@ubuntumail> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Serge Hallyn Cc: 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, 23 Feb 2015, Serge Hallyn wrote: > 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. I do not see a problem with dropping privilege since the ambient set is supposed to be preserved across a drop of priviledge. > 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, I would say that the ambient set stays active even if the setuid binary drops to regular perms. > 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) Well if the ambient set is completely separate then the existing semantics are preserved while the ambient set stays active as intended.