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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Mar 2018 13:04:16 -0400
From:   Stefan Berger <stefanb@...ux.vnet.ibm.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     mkayaalp@...binghamton.edu,
        Mehmet Kayaalp <mkayaalp@...ux.vnet.ibm.com>,
        sunyuqiong1988@...il.com, containers@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org, david.safford@...com,
        linux-security-module@...r.kernel.org,
        linux-integrity@...r.kernel.org, zohar@...ux.vnet.ibm.com
Subject: Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support

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@...hat.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