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

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

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.

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 ?

appraisal to be turned on unless the owner asks for it, in which case
it's caveat emptor: As it works today, if as root I add a default
appraisal policy to IMA without either a key or xattrs, I get an
unusable system.

    Stefan

James

--
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