From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753271AbdGYTsS (ORCPT ); Tue, 25 Jul 2017 15:48:18 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57844 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751530AbdGYTsP (ORCPT ); Tue, 25 Jul 2017 15:48:15 -0400 Subject: Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support From: Mimi Zohar To: James Bottomley , "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 15:48:02 -0400 In-Reply-To: <1501009739.3689.33.camel@HansenPartnership.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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable x-cbid: 17072519-1617-0000-0000-000001F8CD66 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072519-1618-0000-0000-0000484248E1 Message-Id: <1501012082.27413.17.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-25_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707250306 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: > > > > > > > > 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? It isn't just the keyrings that need to be namespaced, but the measurement list and policy as well. 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. Mimi