Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   ebiederm@xmission.com (Eric W. Biederman)
To:     Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc:     James Bottomley <James.Bottomley@HansenPartnership.com>,
        mkayaalp@cs.binghamton.edu,
        Mehmet Kayaalp <mkayaalp@linux.vnet.ibm.com>,
        sunyuqiong1988@gmail.com, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, david.safford@ge.com,
        linux-security-module@vger.kernel.org,
        linux-integrity@vger.kernel.org, zohar@linux.vnet.ibm.com
References: <20180309201421.6150-1-stefanb@linux.vnet.ibm.com>
        <20180309201421.6150-2-stefanb@linux.vnet.ibm.com>
        <87vadxfwqj.fsf@xmission.com>
        <c18b6e92-57f0-5994-eb60-5fadc6671832@linux.vnet.ibm.com>
        <1521135192.5348.64.camel@HansenPartnership.com>
        <2183a3b4-6270-d2e9-70ad-a7399eb1681c@linux.vnet.ibm.com>
        <1521139535.5348.89.camel@HansenPartnership.com>
        <0dc5b856-8dc6-7b5a-eeac-febd19f6498c@linux.vnet.ibm.com>
        <1521140467.5348.94.camel@HansenPartnership.com>
        <056e5b9e-b4d3-1862-baea-06dda4bd0713@linux.vnet.ibm.com>
Date:   Thu, 15 Mar 2018 14:20:31 -0500
In-Reply-To: <056e5b9e-b4d3-1862-baea-06dda4bd0713@linux.vnet.ibm.com> (Stefan
        Berger's message of "Thu, 15 Mar 2018 15:15:25 -0400")
Message-ID: <87sh915eo0.fsf@xmission.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Stefan Berger <stefanb@linux.vnet.ibm.com> writes:

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

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.

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.

Eric