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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ