Message-ID: <2ea23569-6fb2-4a4e-acc1-e3927dd5615d@schaufler-ca.com>
Date: Fri, 27 Sep 2024 09:33:19 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: "Dr. Greg" <greg@...ellic.com>, Paul Moore <paul@...l-moore.com>
Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org,
 Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [GIT PULL] lsm/lsm-pr-20240911

On 9/27/2024 1:58 AM, Dr. Greg wrote:
> On Mon, Sep 16, 2024 at 04:08:11AM -0400, Paul Moore wrote:
>
> Good morning, I hope the end of the week is going well for everyone.
>
>> On Sun, Sep 15, 2024 at 8:38???PM Tetsuo Handa
>> <penguin-kernel@...ove.sakura.ne.jp> wrote:
>>> On 2024/09/14 0:28, Paul Moore wrote:
>>>> I find it somewhat amusing that you are complaining about the LSM
>>>> framework not accepting new LSMs in the same pull request where we are
>>>> adding a new LSM (IPE).  As a reminder, we have documented guidelines
>>>> regarding the addition of new LSMs:
>>>>
>>>> https://github.com/LinuxSecurityModule/kernel/blob/main/README.md
>>> (...snipped...)
>>>> While I have no intention to negatively impact out-of-tree LSMs,
>>> What I call "patent examination" is "New LSM Guidelines" section within
>>> that link. That section includes "here are a list of requirements for
>>> new LSM submissions:" and "The new LSM must be sufficiently unique", and
>>> out-of-tree LSMs which cannot satisfy it won't be able to become in-tree.
>>> If we apply this requirement to userspace program, this requirement means
>>> you are declaring that "postfix" (or anything except "sendmail") cannot
>>> become in-tree because "sendmail" is already in-tree. This is a clear
>>> intention of negatively impact out-of-tree LSMs. People have the right to
>>> use whatever subsets/alternatives. Even if a new LSM has were completely a
>>> subset of existing in-tree LSMs, people have the right to use such LSM.
>> Comparing userspace applications to kernel code isn't a fair
>> comparison as a userspace application can generally be added without
>> impacting the other applications on the system.
> Tetsuo's comparison may be a bit strained, but it remains relevant.
>
> Linux was founded on a concept of choice, the current LSM architecture
> struggles with the ability to facilitate generalized choice and
> flexibility.
>
>>> While I consider that some of out-of-tree LSMs being unable to
>>> become in-tree is inevitable, the requirement that any LSM has to
>>> be built-in is a barrier for LSMs which cannot be built-in.
>> Anyone is always free to build their own kernel with whatever code
>> changes they like, this is the beauty of the kernel source being
>> available and licensed as Open Source.  You are free to build a
>> kernel with whatever LSM you like included and enabled.  You have
>> been shown examples on how to do this in previous threads.
>>> People have the right to install whatever userspace software /
>>> kernel modules they need.
>> Anyone is free to build their own kernel with whatever LSMs they want,
>> either in-tree or out-of-tree; the static call changes do not prevent
>> that.
> This line of reasoning represents a bit of an indulgence in a false
> binary logic fallacy.
>
> Anyone reading this forum is certainly capable of building a kernel in
> any configuration they want to.  That being said, the general Linux
> technical community now represents a cohort far larger than
> individuals who have the ability to build and platform a kernel of
> their choosing.
>
> From a security perspective, Linux will benefit from providing a
> better means to serve a middle ground where alternate security models
> and architectures can be implemented without building a kernel from
> scratch.

Ye Gads. One can create SELinux policy to support just about any security
model you can think of, although I was the first to decry its complexity.
Smack access rules can be configured to support a wide variety of models,
including Bell & LaPadula, Biba and rings of trust. AppArmor is very useful
for targeted application security model enforcement. And then there's BPF.

It seems to me that the problem isn't with the facilities provided to support
the implementation of new security models, it is with the definition of those
security modules. Or rather, the lack thereof. The ancient Bell & LaPadula
sensitivity model can be implemented using Smack rules because it is
sufficiently well defined. If the end user can define their policy as clearly
as B&P does, its a slam dunk for any of the aforementioned LSMs.

Powered by blists - more mailing lists