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 Content-Length: 1365 Lines: 33 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