Message-ID: <20240927085841.GA3642@wind.enjellic.com>
Date: Fri, 27 Sep 2024 03:58:42 -0500
From: "Dr. Greg" <greg@...ellic.com>
To: 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
Subject: Re: [GIT PULL] lsm/lsm-pr-20240911

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.

> > > My focus is on the upstream Linux kernel and ensuring that the upstream,
> > > in-tree LSMs have the best framework possible to ensure their proper
> > > operation and ease of development/maintenance.  While I have no
> > > intention to negatively impact out-of-tree LSMs, I will not harm the
> > > upstream code base solely to support out-of-tree LSMs.  Further, if
> > > improvements to the upstream LSM framework are determined to harm
> > > out-of-tree LSMs, that shall be no reason to reject the upstream
> > > improvements.
> >
> > I have been asking you for a solution for "in-tree but not built-in" LSM
> > (namely TOMOYO). You are refusing to provide a solution for the sake of
> > "in-tree and built-in" LSMs. The "static call" changes fails to ensure that
> > the upstream, in-tree TOMOYO to have the best framework. The "static call"
> > changes makes the upstream, in-tree TOMOYO to have a worse framework than
> > now.

> As mentioned so many times before, the "in-tree but not built-in"
> LSM problem is entirely a distribution/binary-kernel problem.  The
> upstream kernel community is not responsible for the choices and
> individual build configurations of the different Linux distros.
> Support for mechanisms which allow for dynamic LSMs in pre-built
> distro kernels is something we could consider, but so far everything
> that has been proposed has had a negative impact on the upstream
> kernel sources and has been rejected as a result.

Not everything.

As of the TSEM V4 release, which is now a month old, we have proposed
a middle ground that provides multiple mechanisms for the mainsteam
kernel to support alternate security models in an orthogonal manner,
but it has struggled to receive any significant review.

The V4 release now includes the ability to use loadable modules to
implement customized security models.  The premise for this support is
to replace the need for a dynamic LSM with an LSM that has dynamic
configurability.

Bandwidth is always in short supply, but some internal investigation
by our team has demonstrated that the TSEM architecture can implement
Tomoyo as a loadable security model.

TSEM also provides a framework for servicing the needs of Endpoint
Detection and Response systems without having to write any kernel code
at all.  This same mechanism also facilitates the ability to apply
machine learning detection and intervention models, a capability that
is notably absent from any of the existing LSM's.

For the record and everyone reading along at home, here are the links
to the four releases:

V1:
https://lore.kernel.org/linux-security-module/20230204050954.11583-1-greg@enjellic.com/T/#t

V2:
https://lore.kernel.org/linux-security-module/20230710102319.19716-1-greg@enjellic.com/T/#t

V3:
https://lore.kernel.org/linux-security-module/20240401105015.27614-1-greg@enjellic.com/T/#t

V4:
https://lore.kernel.org/linux-security-module/20240826103728.3378-1-greg@enjellic.com/T/#t

We believe that making some forward progress with review and inclusion
of TSEM would positively impact the issues under discussion.

> paul-moore.com

Have a good weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

Powered by blists - more mailing lists