Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753319AbdGYUbo (ORCPT ); Tue, 25 Jul 2017 16:31:44 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:45730 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753016AbdGYUbl (ORCPT ); Tue, 25 Jul 2017 16:31:41 -0400 Message-ID: <1501014695.3689.41.camel@HansenPartnership.com> Subject: Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support From: James Bottomley To: Mimi Zohar , "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 13:31:35 -0700 In-Reply-To: <1501012082.27413.17.camel@linux.vnet.ibm.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> <1501009739.3689.33.camel@HansenPartnership.com> <1501012082.27413.17.camel@linux.vnet.ibm.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: 2548 Lines: 59 On Tue, 2017-07-25 at 15:48 -0400, Mimi Zohar wrote: > On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > > > > 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: [...] > > > > 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? > > It isn't just the keyrings that need to be namespaced, but the > measurement list and policy as well. OK, so trigger to do a just in time copy would be new key or new policy.  The measurement list is basically just a has of a file taken at a policy point.  Presumably it doesn't change if we install a new policy or key, so it sounds like it should be tied to the underlying mount point?  I'm thinking if we set up a hundred mount ns each pointing to /var/container, we don't want /var/container/bin/something to have 100 separate measurements each with the same hash. > IMA-measurement, IMA-appraisal and IMA-audit are all policy based. > > As soon as the namespace starts, measurements should be added to the > namespace specific measurement list, not it's parent. Would the measurement in a child namespace yield a different measurement in the parent?  I'm thinking not, because a measurement is just a hash.  Now if the signature of the hash in the xattr needs a different key, obviously this differs, but the expensive part (computing the hash) shouldn't change. James > Mimi > > _______________________________________________ > Containers mailing list > Containers@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/containers