Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support

From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: John Johansen <john.johansen@canonical.com>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	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 <James.Bottomley@HansenPartnership.com>,
	Mehmet Kayaalp <mkayaalp@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support
Date: Wed, 18 Apr 2018 16:27:08 -0400	[thread overview]
Message-ID: <1524083228.3272.331.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <87wox4s282.fsf@xmission.com>

On Wed, 2018-04-18 at 15:12 -0500, Eric W. Biederman wrote:
> Mimi Zohar <zohar@linux.vnet.ibm.com> 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