From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751481AbdGYStV (ORCPT ); Tue, 25 Jul 2017 14:49:21 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:44806 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750781AbdGYStT (ORCPT ); Tue, 25 Jul 2017 14:49:19 -0400 Message-ID: <1501008554.3689.30.camel@HansenPartnership.com> Subject: Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support From: James Bottomley To: "Serge E. Hallyn" , Mehmet Kayaalp Cc: Mehmet Kayaalp , Yuqiong Sun , containers , linux-kernel , David Safford , linux-security-module , ima-devel , Yuqiong Sun Date: Tue, 25 Jul 2017 11:49:14 -0700 In-Reply-To: <20170725175317.GA727@mail.hallyn.com> References: <20170720225033.21298-1-mkayaalp@linux.vnet.ibm.com> <20170720225033.21298-2-mkayaalp@linux.vnet.ibm.com> <20170725175317.GA727@mail.hallyn.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp wrote: > > > > From: Yuqiong Sun > > > > Add new CONFIG_IMA_NS config option.  Let clone() create a new IMA > > namespace upon CLONE_NEWNS flag. Add ima_ns data structure in > > nsproxy. > > ima_ns is allocated and freed upon IMA namespace creation and exit. > > Currently, the ima_ns contains no useful IMA data but only a dummy > > interface. This patch creates the framework for namespacing the > > different > > aspects of IMA (eg. IMA-audit, IMA-measurement, IMA-appraisal). > > > > Signed-off-by: Yuqiong Sun > > > > Changelog: > > * Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag > > Hi, > > So this means that every mount namespace clone will clone a new IMA > namespace.  Is that really ok? Based on what: space concerns (struct ima_ns is reasonably small)? or whether tying it to the mount namespace is the correct thing to do.  On the latter, it does seem that this should be a property of either the mount or user ns rather than its own separate ns.  I could see a use where even a container might want multiple ima keyrings within the container (say containerised apache service with multiple tenants), so instinct tells me that mount ns is the correct granularity for this. James From mboxrd@z Thu Jan 1 00:00:00 1970 From: James.Bottomley@HansenPartnership.com (James Bottomley) Date: Tue, 25 Jul 2017 11:49:14 -0700 Subject: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support In-Reply-To: <20170725175317.GA727@mail.hallyn.com> References: <20170720225033.21298-1-mkayaalp@linux.vnet.ibm.com> <20170720225033.21298-2-mkayaalp@linux.vnet.ibm.com> <20170725175317.GA727@mail.hallyn.com> Message-ID: <1501008554.3689.30.camel@HansenPartnership.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp wrote: > > > > From: Yuqiong Sun > > > > Add new CONFIG_IMA_NS config option.??Let clone() create a new IMA > > namespace upon CLONE_NEWNS flag. Add ima_ns data structure in > > nsproxy. > > ima_ns is allocated and freed upon IMA namespace creation and exit. > > Currently, the ima_ns contains no useful IMA data but only a dummy > > interface. This patch creates the framework for namespacing the > > different > > aspects of IMA (eg. IMA-audit, IMA-measurement, IMA-appraisal). > > > > Signed-off-by: Yuqiong Sun > > > > Changelog: > > * Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag > > Hi, > > So this means that every mount namespace clone will clone a new IMA > namespace.??Is that really ok? Based on what: space concerns (struct ima_ns is reasonably small)? or whether tying it to the mount namespace is the correct thing to do. ?On the latter, it does seem that this should be a property of either the mount or user ns rather than its own separate ns. ?I could see a use where even a container might want multiple ima keyrings within the container (say containerised apache service with multiple tenants), so instinct tells me that mount ns is the correct granularity for this. James -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html