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

Stefan Berger [off-list ref] writes:

On 03/15/2018 03:20 PM, Eric W. Biederman wrote:

quoted

Stefan Berger [off-list ref] writes:

quoted

On 03/15/2018 03:01 PM, James Bottomley wrote:

quoted

On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote:

quoted

On 03/15/2018 02:45 PM, James Bottomley wrote:

[...]

quoted

quoted

quoted

quoted

going to need some type of keyring namespace and there's
already
one hanging off the user_ns:

commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e
Author: David Howells [off-list ref]
Date:   Tue Sep 24 10:35:19 2013 +0100

        KEYS: Add per-user_namespace registers for persistent
per-UID
kerberos caches

The benefit for IMA would be that this would then tie the keys
needed for appraising to the IMA namespace's policy.
However, if you have an appraise policy in your IMA namespace,
which is now hooked to the user namespace, and you join that user
namespace but your files don't have signatures, nothing will
execute anymore. That's now a side effect of joining this user
namespace unless we have a magic  exception. My feeling is,
people may not like that...

Agree, but I think the magic might be to populate the ima keyring
with the parent on user_ns creation.  That way the user_ns owner
can delete the parent keys if they don't like them, but by default
the parent appraisal policy should just work.

That may add keys to your keyring but doesn't get you signatures on
your  files.

But it doesn't need to.  The only way we'd get a failure is if the file
is already being appraised and we lose access to the key.  If the

Well, the configuration I talked about above was assuming that we have
an appraisal policy active in the IMA namespace, which is now tied to
the user namespace that was just joined.

If we are fine with the side effects of an IMA policy active as part
of a user namespace then let's go with it. The side effects in case of
an active IMA appraisal may then be that files cannot be
read/accessed, or file measurements or IMA auditing may occur.

The alternative is we have an independent IMA namespace. If one joins
the USER namespace and there are no IMA-related side effects. If one
joins the IMA namespace its IMA policy should start being enforced. If
the current active USER namespace has the keys that go with the
signatures of the filesystem, then we're fine from the appraisal
perspective. If not, then IMA namespace joining may prevent file
accesses.

quoted

parent policy isn't appraisal, entering the IMA NS won't cause

Why parent policy? The policy of the namespace that was joined should
be the active one, no ?

Unless I am completely blind we should never stop enforcing the parent's
polciy.  We should only add policy to enforce for the scope of a
container.

What we want is an independent policy for each IMA namespace.

What we don't want is that root can abuse his power to spawn new namespaces and
circumvent a file appraisal policy on the host (in init_ima_ns). Because of that
root's activities are subject to the IMA policy of the currently active IMA
namespace and the one of init_ima_ns (and possibly all the ones in between). If
root is working in a child IMA namespace and file appraisal fails due to the
policy in init_ima_ns and keys found in .ima or _ima keyrings attached to
init_user_ns, the file access will be denied.

Besides that root's activities will always be measured and audited following the
policy in init_ima_ns. This tries to prevent that root spawns an IMA namespace
with a NULL policy and does things in the TCB and tries to escape the
logging.

That sounds exactly like my definition of hierarchical namespace
enforcement.

And please keep in mind that everyone is allowed to use CLONE_NEWNS now.
You just have to spawn a new user namespace first so you have the caps.

quoted

In practice this is just the containers policy as the container is most
likely a do whatever you want to in the parent policy.  But not always
and not explicitly.

Mount namespaces are not hierarchical, user namespaces are.  Which makes
them much more appropriate for being part of nested policy enforcement.

We don't want additive or hierarchical policies - at least I don't. They should
be independent. Only exception are activities of root that are always
iteratively evaluated against policies of the current IMA NS and the init_ima_ns
and possibly all the ones in between.

I believe that is what I meant by a nested/hiearchical policy
enforcement.

quoted

 From previous conversations I remember that there is a legitimate
bootstrap problem for IMA.  That needs to be looked at, and I am not
seeing that mentioned.

IMA's log should not have a gap. So ideally we shouldn't have to write something
into sysfs to spawn a new IMA namespace so that we don't miss whatever setup may
have happened to get there, including the writing into procfs. IMA should be
there right from the start. So a clone flag would be ideal for that.

Please make that securityfs not sysfs.  Sysfs should be about the
hardware not these higher level software details.  I really don't want
to have to namespace sysfs more than I already have.

As for the no gaps requirement.  That is a powerful lever for ruling out
solutions that don't work as well.



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