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

Mimi Zohar [off-list ref] writes:

On Wed, 2018-04-18 at 09:09 -0700, John Johansen wrote:

quoted

On 04/13/2018 09:25 AM, Mimi Zohar wrote:

quoted

[Cc'ing John Johansen]

On Tue, 2018-03-27 at 18:01 -0500, Eric W. Biederman wrote:
[...]

quoted

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.

quoted

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.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html