linux-kernel - Re: [PATCH 2/2] integrity: double check iint

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <9405bcfc-78bd-8e7f-41d4-b919221f73e4@schaufler-ca.com>
Date:   Thu, 24 Feb 2022 10:51:07 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Petr Vorel <pvorel@...e.cz>
Cc:     zohar@...ux.ibm.com, dvyukov@...gle.com, ebiggers@...nel.org,
        jmorris@...ei.org, keescook@...omium.org,
        linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, serge@...lyn.com,
        Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH 2/2] integrity: double check iint_cache was initialized

On 2/24/2022 9:42 AM, Petr Vorel wrote:
> Hi Casey,
>
>> On 2/24/2022 6:20 AM, Petr Vorel wrote:
>>> Hi Mimi, Tetsuo, Kees, all,
>>> FYI this commit merged as 92063f3ca73a ("integrity: double check iint_cache was initialized")
>>> is the reason for openSUSE distro installer going back from lsm= to deprecated
>>> security= when filling default grub parameters because security=apparmor or
>>> security=selinux does not break boot when used with ima_policy=tcb, unlike
>>> using lsm.
>> OK, color me confused. Integrity isn't an LSM. It doesn't
>> call security_add_hooks().
> Really: "Initially I also questioned making "integrity" an LSM.  Perhaps it's
> time to reconsider." [1]

It was always my expectation, which appears to have been poorly
communicated, that "making integrity an LSM" meant using the LSM
hook infrastructure. Just adding "integrity" to lsm= doesn't make
it an LSM to my mind.

>>> @Kees, @Mimi sure, people who use ima_policy=tcb will just remove lsm parameter
>>> or add "integrity" to it but I wonder whether there could be "integrity"
>>> automatic inclusion when using ima_policy=tcb. Although the point of lsm= (and
>>> CONFIG_LSM) is to have *ordered* list of enabled LSMs and it wouldn't be clear
>>> on which place.
>> Why would adding integrity to the lsm= make sense? It's not an LSM.
>> Sorry, but something is wrong here.
> np. I explained that: try to boot with "ima_policy=tcb lsm=" or "ima_policy=tcb
> lsm=whatever" (whatever != integrity).
>
> Also have look at commit 92063f3ca73a ("integrity: double check iint_cache was
> initialized") which explain why it's needed.

	"The mixed metaphor never boils."

What is bothering me is that IMA, which is not an LSM, depends on the
LSM mechanism for specification. Sigh, I can see that boat has sailed.

Since IMA doesn't use the LSM hook mechanisms (doesn't add hooks to the
hook lists) it shouldn't matter where in the lsm= string "integrity" is
or where in CONFIG_LSM it appears. The ordering is only relevant to the
"registered" hooks, and IMA doesn't register.

... except that it shouldn't be 1st, since "capability" is always supposed
to be 1st. And it shouldn't be last, because BPF whats to be there, and I
can't say if their user-space will handle the lsm string if it isn't.

> Kind regards,
> Petr
>
> [1] https://lore.kernel.org/linux-integrity/3ed2004413e0ac07c7bd6f10294d6b6fac6fdbf3.camel@linux.ibm.com/