On 10/24/2022 8:13 AM, Tetsuo Handa wrote:

On 2022/10/24 2:13, Casey Schaufler wrote:

quoted

quoted

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:

quoted

On 10/23/2022 3:10 AM, Tetsuo Handa wrote:

quoted

On 2022/10/23 16:27, Tetsuo Handa wrote:

quoted

On 2022/10/21 8:42, Casey Schaufler wrote:

quoted

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.