Messages in this thread | | | Subject | Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support | From | Stefan Berger <> | Date | Fri, 16 Mar 2018 13:04:16 -0400 |
| |
On 03/15/2018 03:15 PM, Stefan Berger wrote: > On 03/15/2018 03:01 PM, James Bottomley wrote: >> On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote: >>> On 03/15/2018 02:45 PM, James Bottomley wrote: >> [...] >>>>>> going to need some type of keyring namespace and there's >>>>>> already >>>>>> one hanging off the user_ns: >>>>>> >>>>>> commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e >>>>>> Author: David Howells <dhowells@redhat.com> >>>>>> 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.
With these differences pointed out, which path do we want to go now ? Eric ? James ?
Stefan
| |