Message-ID: <7263e155-9024-0508-370c-72692901b326@schaufler-ca.com>
Date:   Mon, 24 Oct 2022 09:37:52 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        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,
        casey@...aufler-ca.com
Subject: Re: [PATCH v38 04/39] LSM: Maintain a table of LSM attribute data

On 10/24/2022 8:13 AM, Tetsuo Handa wrote:
> On 2022/10/24 2:13, Casey Schaufler wrote:
>>> We won't be able to accept whatever LSM modules to upstream, and we won't
>>> be able to enable whatever LSM modules in distributor kernels.
>> A built in module loader security module would address this issue.
>> Getting such a module accepted upstream is not going to be trivial,
>> but the BPF people seem to have managed it.
> How can we guarantee that a built-in module loader security module is
> always built-in ?

You can't. That's up to the distribution. Just like BPF.

>  What I'm insisting is that "warrant the freedom to load
> loadable LSM modules without recompiling the whole kernel".

Since security modules are optional and the LSM infrastructure
itself is optional you can't ensure that any given kernel would
support a loadable security module.

> Sure, we can load LSM modules which were not built into distributor kernels
> if we can recompile the whole kernel". But give me a break, that's a stupid
> opinion for non-kernel developers. People won't replace distributor kernels
> with rebuilt kernels only for enabling LSM modules which were not built into
> distributor kernels.
>
> Quoting from https://lkml.kernel.org/r/7f9ffd77-a329-ab13-857b-f8e34b2bfc77@schaufler-ca.com
>
>   > I'm waiting to see what happens if eBPF security modules
>   > become popular. I can easily see distributions turning the BPF LSM off.
>
> Even if TOMOYO could be rewritten in eBPF (I don't think it is possible), how TOMOYO
> can be loaded into distributor kernels if distributions turn the BPF LSM off ?
>
>   > Before I go any further, I think that the loadable module manager LSM would be
>   > very hard to get upstream.
>
> Not only it will be very hard to get the loadable module manager LSM upstream,
> it will be also very hard to keep the loadable module manager LSM enabled in
> distributor kernels.

That is correct.

>
> Again, how can we guarantee that a built-in module loader security module is
> always built-in ?

Again, you can't. You can't guarantee that the LSM infrastructure is built in.

> What I'm insisting is that "warrant the freedom to load loadable LSM modules
> without recompiling the whole kernel".
>
> Adding EXPORT_SYMBOL_GPL(security_hook_heads) is the only way that can "allow
> LSM modules which distributors cannot support to be legally loaded".

I believe that I've identified an alternative. It isn't easy or cheap.

>
> Any fixed-sized array like lsm_idlist[LSMID_ENTRIES] that defines max capacity
> based on whether that LSM module is built-in will lock out loadable LSM modules.
> Thus, I'm not happy with LSMID_ENTRIES.
>
>
>
> On 2022/10/24 2:20, Casey Schaufler wrote:
>> On 10/23/2022 3:10 AM, Tetsuo Handa wrote:
>>> 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...
>> It's really no more dangerous than using the LSM name. What if two developers
>> implement modules and both name it "belllapadula"? User space won't be able to
>> tell the difference if they base behavior on the module name. That's one thing
>> that a loadable module mechanism is going to need to address that a built-in
>> mechanism doesn't. 
> If the upstream kernel assigns an LSM id for all LSM modules including out-of-tree
> and/or private LSM modules (that's why I described that the upstream kernel behaves
> as if a DNS registerer), we can assign LSM id = 100 to "belllapadula" from A and
> LSM id = 101 to "belllapadula" from B, and both "belllapadula" modules can work
> without conflicts by using LSM id. Of course, this implies that we need to preserve
> unused space in lsm_idlist[LSMID_ENTRIES] etc. for such LSM modules (if we use
> fixed-sized array rather than a linked list).

Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
security modules. That's one of many reasons loadable modules are going to
have to be treated differently from built-in modules, if they're allowed
at all.

Powered by blists - more mailing lists