Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753507AbbBBRTW (ORCPT ); Mon, 2 Feb 2015 12:19:22 -0500 Received: from mail-la0-f51.google.com ([209.85.215.51]:45877 "EHLO mail-la0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751753AbbBBRTU (ORCPT ); Mon, 2 Feb 2015 12:19:20 -0500 MIME-Version: 1.0 In-Reply-To: <20150202171257.GD24351@ubuntumail> References: <20150202171257.GD24351@ubuntumail> From: Andy Lutomirski Date: Mon, 2 Feb 2015 09:18:58 -0800 Message-ID: Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities To: Serge Hallyn Cc: Christoph Lameter , Serge Hallyn , Jonathan Corbet , Aaron Jones , "Ted Ts'o" , LSM List , "linux-kernel@vger.kernel.org" , Andrew Morton , "Andrew G. Morgan" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1541 Lines: 35 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. 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. --Andy -- 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/