From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:56802 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750981AbeDRU1R (ORCPT ); Wed, 18 Apr 2018 16:27:17 -0400 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3IKOuV9051316 for ; Wed, 18 Apr 2018 16:27:17 -0400 Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by mx0b-001b2d01.pphosted.com with ESMTP id 2he986tpn7-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Wed, 18 Apr 2018 16:27:16 -0400 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 18 Apr 2018 21:27:14 +0100 Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support From: Mimi Zohar To: "Eric W. Biederman" Cc: John Johansen , Stefan Berger , linux-integrity@vger.kernel.org, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, serge@hallyn.com, sunyuqiong1988@gmail.com, david.safford@ge.com, mkayaalp@cs.binghamton.edu, James Bottomley , Mehmet Kayaalp Date: Wed, 18 Apr 2018 16:27:08 -0400 In-Reply-To: <87wox4s282.fsf@xmission.com> References: <1522159038-14175-1-git-send-email-stefanb@linux.vnet.ibm.com> <1522159038-14175-2-git-send-email-stefanb@linux.vnet.ibm.com> <87sh8lcecn.fsf@xmission.com> <1523636702.3272.63.camel@linux.vnet.ibm.com> <1524081472.3272.319.camel@linux.vnet.ibm.com> <87wox4s282.fsf@xmission.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Message-Id: <1524083228.3272.331.camel@linux.vnet.ibm.com> Sender: linux-integrity-owner@vger.kernel.org List-ID: On Wed, 2018-04-18 at 15:12 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > On Wed, 2018-04-18 at 09:09 -0700, John Johansen wrote: > >> On 04/13/2018 09:25 AM, Mimi Zohar wrote: > >> > [Cc'ing John Johansen] > >> > > >> > On Tue, 2018-03-27 at 18:01 -0500, Eric W. Biederman wrote: > >> > [...] > >> >> As such I expect the best way to create the ima namespace is by simply > >> >> writing to securityfs/imafs. Possibly before the user namespace is > >> >> even unshared. That would allow IMA to keep track of things from > >> >> before a container is created. > >> > > >> > >> I do think this is generally the right approach for LSMs when looking > >> forward to LSM stacking and more LSMs. > >> > >> > >> > My initial thought was to stage IMA namespacing with just IMA-audit > >> > first, followed by either IMA-measurement or IMA-appraisal. This > >> > would allow us to get the basic IMA namespacing framework working and > >> > defer dealing with the securityfs related namespacing of the IMA > >> > policy and measurement list issues to later. > >> > > >> > By tying IMA namespacing to a securityfs ima/unshare file, we would > >> > need to address the securityfs issues first. > >> > > >> > >> well it depends on what you want to do. It would be possible to have > >> a simple file (not a jump link) within securityfs that IMA could use > >> without having to deal with all the securityfs issues first. However it > >> does require that securityfs (not necessarily imafs) be visible within > >> the mount namespace of the task doing the setup. > > > > Eric, would you be OK with that? > > Roughly. My understanding is that you have to have a write to some > filesystem to set the ima policy. > > I was expecting having to write an "create ima namespace" value > to the filesystem would not be any special effort. > > Now it sounds like providing the "create an ima namespace" is going to > be a special case, and that does not sound correct. This is not any different than any of the other security/ima/ files (eg. policy, ascii_runtime_measurements, ...). The next IMA namespacing stage would add support for these files. Mimi