Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v5 3/4] LSM: Define SELinux function to measure state and
 policy
From:   Stephen Smalley <stephen.smalley.work@gmail.com>
To:     Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Cc:     Mimi Zohar <zohar@linux.ibm.com>,
        Casey Schaufler <casey@schaufler-ca.com>,
        Tyler Hicks <tyhicks@linux.microsoft.com>, sashal@kernel.org,
        James Morris <jmorris@namei.org>,
        linux-integrity@vger.kernel.org,
        SElinux list <selinux@vger.kernel.org>,
        LSM List <linux-security-module@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
References: <20200730034724.3298-1-nramas@linux.microsoft.com>
 <20200730034724.3298-4-nramas@linux.microsoft.com>
 <dfd6f9c8-d62a-d278-9b0e-6b1f5ad03d3e@gmail.com>
 <6371efa9-5ae6-05ac-c357-3fbe1a5a93d5@linux.microsoft.com>
 <CAEjxPJ789kmdDwy-6RaL7HuMFxKpQ9Hwxj9J-_-f62XDCNJUiA@mail.gmail.com>
 <f992901f-6dca-7d31-3426-5a74d36c2c8c@gmail.com>
 <d988a6d0-04e0-62f0-2705-4352b268ca55@linux.microsoft.com>
 <5c843a3d-713c-e71f-8d4f-c6e5f51422f1@gmail.com>
 <3e766eed-7a0b-afca-6139-ac43dea053d7@linux.microsoft.com>
 <0fa0b1f3-6226-c307-0f11-8b3a881a070e@gmail.com>
Message-ID: <32da0a4a-252a-67d8-5dc8-173959f6ddb4@gmail.com>
Date:   Tue, 4 Aug 2020 11:29:38 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <0fa0b1f3-6226-c307-0f11-8b3a881a070e@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 8/4/20 11:20 AM, Stephen Smalley wrote:

> On 8/3/20 6:08 PM, Lakshmi Ramasubramanian wrote:
>
>> On 8/3/20 2:07 PM, Stephen Smalley wrote:
>>
>>>>>> [   68.870715] irq event stamp: 23486085
>>>>>> [   68.870715] hardirqs last  enabled at (23486085):
>>>>>> [<ffffffffaa419406>] _raw_spin_unlock_irqrestore+0x46/0x60
>>>>>> [   68.870715] hardirqs last disabled at (23486084):
>>>>>> [<ffffffffaa419443>] _raw_spin_lock_irqsave+0x23/0x90
>>>>>> [   68.870715] softirqs last  enabled at (23486074):
>>>>>> [<ffffffffaa8004f3>] __do_softirq+0x4f3/0x662
>>>>>> [   68.870715] softirqs last disabled at (23486067):
>>>>>> [<ffffffffaa601072>] asm_call_on_stack+0x12/0x20
>>>>>> [   68.870715] ---[ end trace fb02740ff6f4d0cd ]---
>>>>>
>>>>> I think one issue here is that systemd loads SELinux policy first, 
>>>>> then IMA policy, so it doesn't know whether it needs to measure 
>>>>> SELinux policy on first policy load, and another issue is that the 
>>>>> policy is too large to just queue the policy data itself this way 
>>>>> (or you need to use an allocator that can handle larger sizes).
>>>>>
>>>>
>>>> The problem seems to be that a lock is held when the IMA hook to 
>>>> measure the LSM state is called. So memory allocation is not 
>>>> allowed, but the hook is doing an allocation. I'll address this - 
>>>> thanks for catching it.
>>>>
>>>> I have the following CONFIGs enabled, but I still don't see the 
>>>> above issue on my machine.
>>>>
>>> The warning has to do with the memory allocation order being above 
>>> the max order supported for kmalloc.  I think the problem is that 
>>> ima_alloc_data_entry() is using kmemdup() to duplicate a payload of 
>>> arbitrary size.  Policies on e.g. Fedora can be quite large, so you 
>>> can't assume they can be allocated with kmalloc and friends.
>>>
>>
>> Thanks for clarifying. Yes ima_alloc_entry() does use kmemdup to save 
>> the given buffer (to be measured) until IMA loads custom policy.
>>
>> On my machine the SELinux policy size is about 2MB.
>>
>> Perhaps vmalloc would be better than using kmalloc? If there are 
>> better options for such large buffer allocation, please let me know.
>
> kvmalloc() can be used to select whichever one is most appropriate.

Other option would be for ima to compute and save the hash(es) of the 
payload and not the payload itself for later use.  I guess you won't 
know at that point which hash algorithm is desired?