[GIT PULL] lsm/lsm-pr-20240911

[Dr. Greg]

On Fri, Sep 27, 2024 at 09:33:19AM -0700, Casey Schaufler wrote:

Good morning Casey, always good to get your reflections, we hope your
week is starting well.

> 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 at i-love.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.

That certainly dates both of us, the last time I heard that phrase it
was from Thurston Howell the III....

> 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.

We certainly wouldn't choose to argue with any of this, given your
repertoire in the field of mandatory access controls and security
models.

But therein lies the rub with respect to the implementation of system
security.

There are what, maybe 5-6 people in the world like yourself, that have
the technical chops to translate the theoretical expressiveness you
describe above into functional, let alone maintainable, security
implementations?

If there was the ability to practically implement just about any
security model with SeLinux there would be no need for the LSM, yet
its existence has arisen, given the desire to support multiple
security schemes.  That alone would seem to suggest the lack of
technical prowess that is required to translate theoretical
expressiveness into practical implementations.

A primary challenge to security is scale of skill.

In the face of limited advanced security skills, we have hundreds of
thousands of people around the world creating and modifying millions
of workloads, on a daily basis.

I mentioned just recently, in a meeting with technical influencers
here in the Great State of North Dakota, that we are never going to
train our way out of this security problem.

Cisco recognized this with network security and this fact was central
to the concept of it's Application Centric Infrastructure (ACI).  With
respect to scale, ACI is based on the premise that the manageability
of network security has to be an artifact of the development process.

One of the motivations behind TSEM is to deliver that same concept to
system security.  The notion of allowing development teams to create a
customized, bounded and mandatorily enforced security behavior,
specific to a workload, as an extension of the development process.

Another tool in the 'Secure By Design' toolbox.  A concept that
entities like NIST, DHS/CISA and particularly the insurance companies
are going to force the industry to translate into practice,
particularly in critical infrastructure systems.

Have a good week.

As always,
Dr. Greg

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