Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932169AbbBZU64 (ORCPT ); Thu, 26 Feb 2015 15:58:56 -0500 Received: from mail-la0-f54.google.com ([209.85.215.54]:37949 "EHLO mail-la0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753942AbbBZU6y (ORCPT ); Thu, 26 Feb 2015 15:58:54 -0500 MIME-Version: 1.0 In-Reply-To: <20150226205512.GA19273@mail.hallyn.com> References: <20150224164429.GB29685@ubuntumail> <20150225033247.GC29685@ubuntumail> <20150226153524.GC15182@mail.hallyn.com> <20150226193200.GA17709@mail.hallyn.com> <20150226203405.GB18926@mail.hallyn.com> <20150226205512.GA19273@mail.hallyn.com> From: Andy Lutomirski Date: Thu, 26 Feb 2015 12:58:33 -0800 Message-ID: Subject: Re: [PATCH] capabilities: Ambient capability set V1 To: "Serge E. Hallyn" Cc: Christoph Lameter , Serge Hallyn , 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 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: 2240 Lines: 64 On Thu, Feb 26, 2015 at 12:55 PM, Serge E. Hallyn wrote: > On Thu, Feb 26, 2015 at 12:51:57PM -0800, Andy Lutomirski wrote: >> On Thu, Feb 26, 2015 at 12:34 PM, Serge E. Hallyn wrote: >> > On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote: >> >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote: >> >> >> >> > Andrew Morgan was against that. What if we changed >> >> > >> >> > pE' = pP' & (fE | pA) >> >> > >> >> > to >> >> > >> >> > if (pA) >> >> > pE' = pP' & fE >> >> > else >> >> > pE' = pP' >> >> > >> >> >> >> Same problem as before. The ambient bits will not be set in pE'. >> > >> > And what if I weren't scatterbrained and we did >> > >> > if (pA) >> > pE' = pP' >> > else >> > pE' = pP' & fE >> > >> > All pP' bits would be set in pE'. >> >> That seems reasonable to me, except for my paranoia: >> >> What if there's a program with CAP_DAC_OVERRIDE in fP and fE set to >> the empty set (i.e. the magic effective bit cleared), and the program >> relies on that. A malicious user has CAP_NET_BIND and sets pA = >> CAP_NET_BIND. Boom! >> >> If we changed that to if (pA') and zeroed pA if fP is non-empty then >> this problem goes away. > > Hm, the problem is that then the empty pA is inherited by children. > I do see that any program with fP set should probably run with only > what it requested. Would > > if (pA && is_empty(fP)) > pE' = pP' > else > pE' = pP' & fE > > help? Or are you worried about a program with fP set which then > executes other programs? The particular worry I expressed there was just about pE. I'm still extremely nervous about allowing nonempty pA to propagate to setuid or nonzero fP programs. It's less obviously dangerous if pA is never a superset of pP, but it could still cause problems with setuid programs that execute intentionally deprivileged helpers. --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/