Sitting at the SELinux symposium this week, I’ve heard some of the smartest people in the room compare SELinux’ current state to assembly language—and they want better languages. But I just heard a different speaker suggest that an administrator faced with difficult SELinux policy authoring “make the computer do the hard work for you.”

But this is a special sort of work. This work is a kind of thinking. Historically, computers have only rarely been good at thinking work. In fact, they’re only good at one very special sort of thinking work: those where we can express a simple algorithm that can be reliably applied. For example, computers are good at playing Chess, but not so good at solving or writing chess problems interesting to humans. Computers are not generally good at creative thinking. It’s troublesome to need to restate this.

Given this constraint, obvious as it should be, how did we get past assembly language? We built compilers. We built interpreters. We built libraries, particularly sophisticated runtime libraries, bringing the flexibility of interpreters to compiled languages. What’s the biggest advantage of modern languages over assembly languages? I don’t expect much contradiction when I celebrate the Garbage Collector.

A simple GC can be written in assembly language, then used by other assembled programs. A simple compiler can be written in assembly language, then used to produce new programs. The first LISP interpreters were written in an assembly language 50 years ago using just this strategy. The core idea here is abstraction: building tools with simpler interfaces than contents. And the SELinux community have provided some abstractions. But they haven’t provided them using SELinux. They’ve provided them using components outside the system. This is more like a card-punch than a compiler.

There is no ability to use SELinux itself to build new SELinux capability. In that critical way, it is not like assembly language. We should not expect to see self-reinforcing, exponential growth in SELinux capability: SELinux, as a constraining rather than enabling system, is not the right shape for that.