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: [RFC PATCH 2/2] integrity: double check iint_cache was
 initialized
To:     Dmitry Vyukov <dvyukov@google.com>,
        Mimi Zohar <zohar@linux.ibm.com>
Cc:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
        linux-integrity@vger.kernel.org, James Morris <jmorris@namei.org>,
        "Serge E . Hallyn" <serge@hallyn.com>,
        linux-security-module <linux-security-module@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Eric Biggers <ebiggers@kernel.org>,
        Casey Schaufler <casey@schaufler-ca.com>
References: <20210319200358.22816-1-zohar@linux.ibm.com>
 <8450c80a-104a-3f36-0963-0ae8fa69e0f2@i-love.sakura.ne.jp>
 <CACT4Y+bvakfNhVs29QvbY6Z8Pw0zmAUKGWM-DD5DcPZW5ny90A@mail.gmail.com>
 <1a2245c6-3cab-7085-83d3-55b083619303@i-love.sakura.ne.jp>
 <8039976be3df9bd07374fe4f1931b8ce28b89dab.camel@linux.ibm.com>
 <cde00350-2a18-1759-d53b-2e7489b6cc0e@i-love.sakura.ne.jp>
 <8a8763a7-eeeb-3578-d50c-c15919fbe1f9@i-love.sakura.ne.jp>
 <3ed2004413e0ac07c7bd6f10294d6b6fac6fdbf3.camel@linux.ibm.com>
 <cc01e7b7-d685-289c-a792-fc76fabba807@i-love.sakura.ne.jp>
 <721b4f8d38b014babb0f4ae829d76014bbf7734e.camel@linux.ibm.com>
 <0a0c5cc5-0e1b-ef01-60c4-5247af2124f4@i-love.sakura.ne.jp>
 <37aeaf361bfbd800e29db761f5160f2ce1869298.camel@linux.ibm.com>
 <05ca20d0-9596-152e-4da2-1ffe28c52055@i-love.sakura.ne.jp>
 <CACT4Y+Y+wzPytH7hMAn3O6zT0p2D4UyQwDbuKbUqc4REzPECkw@mail.gmail.com>
 <ca2b63a47c2910072397d41448c46293750456f7.camel@linux.ibm.com>
 <CACT4Y+YatH2MHMh5s1KJtb-5w-RvmZPtQyRZqpVk=YP=HJYMkg@mail.gmail.com>
From:   Casey Schaufler <casey@schaufler-ca.com>
Message-ID: <cff37d9a-67a4-773b-6a56-313a369f4a11@schaufler-ca.com>
Date:   Wed, 24 Mar 2021 08:56:18 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <CACT4Y+YatH2MHMh5s1KJtb-5w-RvmZPtQyRZqpVk=YP=HJYMkg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Content-Length: 3290
Precedence: bulk

On 3/24/2021 4:58 AM, Dmitry Vyukov wrote:
> On Wed, Mar 24, 2021 at 12:49 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
>> On Wed, 2021-03-24 at 12:37 +0100, Dmitry Vyukov wrote:
>>> On Wed, Mar 24, 2021 at 12:21 PM Tetsuo Handa
>>> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>>> On 2021/03/24 20:10, Mimi Zohar wrote:
>>>>> On Wed, 2021-03-24 at 19:10 +0900, Tetsuo Handa wrote:
>>>>>> On 2021/03/24 1:13, Mimi Zohar wrote:
>>>>>>> On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote:
>>>>>>>> On 2021/03/23 23:47, Mimi Zohar wrote:
>>>>>>>>> Initially I also questioned making "integrity" an LSM.  Perhaps it's
>>>>>>>>> time to reconsider.   For now, it makes sense to just fix the NULL
>>>>>>>>> pointer dereferencing.
>>>>>>>> Do we think calling panic() as "fix the NULL pointer dereferencing" ?
>>>>>>> Not supplying "integrity" as an "lsm=" option is a user error.  There
>>>>>>> are only two options - allow or deny the caller to proceed.   If the
>>>>>>> user is expecting the integrity subsystem to be properly working,
>>>>>>> returning a NULL and allowing the system to boot (RFC patch version)
>>>>>>> does not make sense.   Better to fail early.
>>>>>> What does the "user" mean? Those who load the vmlinux?
>>>>>> Only the "root" user (so called administrators)?
>>>>>> Any users including other than "root" user?
>>>>>>
>>>>>> If the user means those who load the vmlinux, that user is explicitly asking
>>>>>> for disabling "integrity" for some reason. In that case, it is a bug if
>>>>>> booting with "integrity" disabled is impossible.
>>>>>>
>>>>>> If the user means something other than those who load the vmlinux,
>>>>>> is there a possibility that that user (especially non "root" users) is
>>>>>> allowed to try to use "integrity" ? If processes other than global init
>>>>>> process can try to use "integrity", wouldn't it be a DoS attack vector?
>>>>>> Please explain in the descripotion why calling panic() does not cause
>>>>>> DoS attack vector.
>>>>> User in this case, is anyone rebooting the system and is intentionally
>>>>> changing the default values, dropping the "integrity" option on the
>>>>> boot command line.
>>>> OK. Then, I expect that the system boots instead of calling panic().
>>>> That user is explicitly asking for disabling "integrity" for some reason.
>>> That was actually my intention. The prebuilt kernel that I use for
>>> things has all LSMs enabled, but then I needed to try some workload
>>> with only 1 specific LSM, so I gave a different lsm= argument.
>> IMA/EVM is dependent on "integrity".  Was your intention to also
>> disable IMA and EVM?
> I think, yes... or not sure. I was trying to test a bug that requires
> a different major LSM and all minor LSMs are presumably irrelevant. I
> dropped existing lsm= arg and added something like lsm=apparmor.

This is the legacy case that security= supports. If you specify
security=apparmor you will get all the "minor" LSMs you have compiled
in and the "major" LSM you've specified, AppArmor in this case. This
is exactly the behavior you used to get before lsm= was introduced.

>
>> If so, when disabling "integrity", don't load an
>> IMA policy.
> I don't really know what this means. I guess it simply comes from the
> image? If so, there was no easy way to avoid loading.