linux-kernel - Re: [PATCH v38 04/39] LSM: Maintain a table of LSM attribute data

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:   Sun, 23 Oct 2022 19:10:42 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     Casey Schaufler <casey@...aufler-ca.com>,
        casey.schaufler@...el.com, paul@...l-moore.com,
        linux-security-module@...r.kernel.org
Cc:     linux-audit@...hat.com, jmorris@...ei.org, selinux@...r.kernel.org,
        keescook@...omium.org, john.johansen@...onical.com,
        stephen.smalley.work@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v38 04/39] LSM: Maintain a table of LSM attribute data

On 2022/10/23 16:27, Tetsuo Handa wrote:
> On 2022/10/21 8:42, Casey Schaufler wrote:
>> I will, on the other hand, listen to compelling arguments. It is not the
>> intention of this code to lock out loadable modules. If I thought it would
>> I would not have proposed it.
> 
> This code is exactly for locking out loadable modules.
> 

Imagine a situation where two individuals independently develop their own
web applications using the same identifier, and then their web applications
started working together with other web applications using that identifier.
When they published their web applications for public and wider use, a problem
that both web applications are already using the same identifier arises.
It is too late to reassign the identifier.

The same trouble can happen with loadable LSM modules. Unless the upstream kernel
behaves as if a DNS registerer that assigns a unique domainname for whatever web
sites (regardless of whether a web site is for public or not), defining a permanent
constant for LSM module is a way towards locking out loadable LSM modules. And it
is well possible that a loadable LSM module wants to run on older kernels which
do not have LSM id defined yet.

This "define LSM id as userspace visible constant" is more dangerous than just
reserving some space for future use. You are trying to control all IP addresses
for the sake of only in-tree LSM modules. No, no, no, please don't do that...