From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754574AbbBBSKB (ORCPT ); Mon, 2 Feb 2015 13:10:01 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:46004 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753968AbbBBSJ6 (ORCPT ); Mon, 2 Feb 2015 13:09:58 -0500 Date: Mon, 2 Feb 2015 18:09:52 +0000 From: Serge Hallyn To: Andy Lutomirski Cc: Christoph Lameter , Serge Hallyn , Jonathan Corbet , Aaron Jones , "Ted Ts'o" , LSM List , "linux-kernel@vger.kernel.org" , Andrew Morton , "Andrew G. Morgan" Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities Message-ID: <20150202180952.GF24351@ubuntumail> References: <20150202171257.GD24351@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 Quoting Andy Lutomirski (luto@amacapital.net): > On Mon, Feb 2, 2015 at 9:12 AM, Serge Hallyn wrote: > > A key concept behind posix capabilities is that the privilege comes from > > both the person and the file being executed. As you say below basically > > anything can be executed by the program so that is completely violated. > > > > Still, it's not that different from mmapping some arbitrary code and > > jumping into it whlie retaining caps. > > > > If we were to support such a feature, I'm thinking I'd prefer we do > > it somewhat analogously to the capability bounding set. Perhaps add a > > ambient_inh_caps set or something. Empty by default. To add caps to it you > > must have the cap in your permitted set already. (Ok to do in a user > > namespace). Then at exec, > > > > pP' = (X & fP) | (pI & fI) | (pI & pA) > > > > pA being your ambient_inh set > > > > Not saying this is a good idea necessarily, but worth thinking about. > > This isn't obviously a bad formulation. We could control pA using some syscall. My first thought was prctl (since we have PR_CAPBSET_DROP) > Another formulation would be a single per-user-ns or > inherited-per-process bit that sets fI to the full set regardless of > file caps. Dealing with the file effective bit will be an added > complication, as will dealing with setuid binaries. > > How many of you will be at LSF/MM? This might be a decent topic. I'm not scheduled to be there.