Re: [PATCH v4 2/14] Add TSEM specific documentation.

["Dr. Greg" <greg@enjellic.com>]

On Tue, Jan 21, 2025 at 10:09:59AM -0800, Casey Schaufler wrote:

Hi Casey, I hope your weekend has gone well, greetings to other on the
list as well.

> On 1/18/2025 11:03 AM, Dr. Greg wrote:
> > On Fri, Jan 17, 2025 at 10:10:30AM -0800, Casey Schaufler wrote:
> >
> > Good morning Casey, I hope your weekend is going well, thanks for
> > taking the time to forward along your thoughts on our work.
> >
> >> On 1/16/2025 8:47 PM, Dr. Greg wrote:
> >>> On Mon, Jan 13, 2025 at 08:29:47PM -0500, Paul Moore wrote:
> >>>
> >> ...
> >>
> >>>> Please define the CELL acronym here as I believe it is the first use of
> >>>> "CELL" in this document.
> >>> FWIW, CELL isn't an acronym, it is a metaphor.
> >>>
> >>> TSEM was conceptually inspired by and derived from the Turing Abstract
> >>> Machine Model (TAMM), as applied to the problem of modeling the
> >>> security state of an execution domain.
> >>>
> >>> As everyone reading this knows, a TAMM, in practice, consists of a
> >>> head traversing an infinite paper tape divided into cells that direct
> >>> the next state of the machine.
> >>>
> >>> In TSEM, the model consists of a Context Of Execution (COE) with
> >>> security definining characteristics, traversing a finite set of
> >>> measurement points of infinite length, with defining characteristics
> >>> at each point.
> >>>
> >>> We refer to a measurement point and its characteristics as a CELL in
> >>> deference to the inspiration for all of this.
> >>>
> >>> We will add this explanation to the documentation.
> >> Communication within a community as culturally diverse as the Linux
> >> kernel developers* requires that you do not assume that "everyone reading
> >> this" knows much of anything beyond how to type "make". Let's face it,
> >> there are kernel developers today who would look at the Turing test and
> >> say "is that even a thing?" There are others who don't have an education
> >> that includes mid-twentieth century technological history.
> >>
> >> [* Yes, an awful lot of Linux kernel developers are western males. ] 
> >>
> >> ...
> > Sigh....
> >
> > It would thus appear that effective dialogue in the Linux kernel
> > community is now about as perilous as attempting to square dance in a
> > minefield with snowshoes on.

> This isn't about Political Correctness. It's about communication.
> Your documentation appears to target PHD level computer scientists.

Probably not surprising, given that Quixote has been architected and
stewarded by three Ph.D.'s, one soon to be Ph.D. and a rather
remarkable individual that has four Ph.D.'s worth of experience, if I
can choose my phrasing carefully, in global cyber-operations of
various types.

> Most Linux kernel developers are much more the BS engineer sort.
> I'm not saying you need to dumb it down, I'm suggesting that you
> could make it easier to review by targeting your audience better.

In the theory portion of the documentation we attempted to draw
correlations between classic mandatory access control and integrity
architectures and what we are implementing with Quixote/TSEM.

> > When we penned the reflections above, we very specifically didot
> > want to be so pejorative as to suggest that anyone involved in this
> > endeavor wouldn't have at least a basic understanding of the
> > computability theory that all of our work is based.  They even have a
> > movie about it, presumably in multiple languages.
> >
> > In any event, we apologize for being mistaken.
> >
> > We will add a Wikipedia link in the documentation pointing to an
> > article on Turing machines, for the benefit of the unwashed masses now
> > involved in kernel development.

> The link is a good idea.

Clarifications to the theory section and a Wikipedia link have been
added and will appear in V5.

> >>> We believe there is a technical solution to this problem as well but
> >>> our work on that front, at this point, is too technically immature to
> >>> go into.

> >> Didn't Pierre de Fermat say something like that about some theorem
> >> or another?

> > As a Quixote team we take some solace to your reference of Fermat's
> > Theorem with respect to our work.  It took 358 years to formally prove
> > his theorem, in the face of many nay-sayers.  It turns out he was
> > absolutely right and his vision is now universally accepted as a
> > foundational premise of mathematics.

> If it takes the Quixote team 358 years to develop a technical
> solution I expect you will miss your market window. :(

If we didn't believe that we have a solid technical solution in hand
within the context of this century, and groups that have asked for it
to be in the kernel, we wouldn't be expending cycles on getting it
upstreamed.

We are hoping for considerably better than 358 years, but that would
seem to be dependent on Linux review bandwidth, which everyone agrees
is strained.

More to the point, we were making an allusion with our comments that
throughout history, disruptive innovation has been consistently missed
by the technical status quo.

Once again, thank you for your comments and review.

Have a good remainder of the weekend.

As always,
Dr. Greg

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