Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750964AbdGYTJ2 (ORCPT ); Tue, 25 Jul 2017 15:09:28 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:45026 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750768AbdGYTJY (ORCPT ); Tue, 25 Jul 2017 15:09:24 -0400 Message-ID: <1501009739.3689.33.camel@HansenPartnership.com> Subject: Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support From: James Bottomley To: "Serge E. Hallyn" Cc: Mehmet Kayaalp , Mehmet Kayaalp , Yuqiong Sun , containers , linux-kernel , David Safford , linux-security-module , ima-devel , Yuqiong Sun Date: Tue, 25 Jul 2017 12:08:59 -0700 In-Reply-To: <20170725190406.GA1883@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> <1501008554.3689.30.camel@HansenPartnership.com> <20170725190406.GA1883@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: 2338 Lines: 56 On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote: > > > > 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 > > Mostly the latter.  The other would be not so much space concerns as > time concerns.  Many things use new mounts namespaces, and we > wouldn't want multiple IMA calls on all file accesses by all of > those. > > > > > 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. > > I wonder whether we could use echo 1 > /sys/kernel/security/ima/newns > as the trigger for requesting a new ima ns on the next > clone(CLONE_NEWNS). I could go with that, but what about the trigger being installing or updating the keyring?  That's the only operation that needs namespace separation, so on mount ns clone, you get a pointer to the old ima_ns until you do something that requires a new key, which then triggers the copy of the namespace and installing it? James