Every time a piece of software encounters a new access pattern, the answer is to tweak the policy. Then tweak it again. Then tweak it again. Then tweak it again. Then tweak it again. At what point does this stop being a security model and start becoming an endless process of granting exceptions?
There is one thing in open source software that consistently consumes more time than it has any right to.
SELinux.
Every few weeks it seems like another SELinux issue appears.
Implementing a new feature? Fix SELinux. Fixing a bug? Fix SELinux. Scratching your butt? Gotta fix your SELinux policy. Repeat forever.
At some point we should start asking the question: What exactly is this accomplishing?
The Concept
The idea is straightforward. If an attacker compromises a process, SELinux limits what that process can access. The attacker is confined to a security domain and prevented from reaching resources outside that domain.
That’s a reasonable goal.
I’m not arguing against the idea of mandatory access control. I’m questioning whether this was the right tradeoff.
The Cost of Convergence
If a piece of software has been around for twenty years, and enough users have run into enough denials, and enough maintainers have added enough exceptions, then sure, maybe the policy eventually becomes stable.
But what a ridiculous way to get there.
The model seems to be: run the software, wait for SELinux to break something, examine the denial, add a rule, repeat until users stop complaining.
That’s not design. That’s playing whac-a-mole.
We’re not thoughtfully defining a security model. We’re painfully discovering the application’s behavior by tripping over every possible thing it might need to do.
An Engineering Failure
SELinux asks us to accept that defining a security model requires years of stumbling over ourselves. I have a hard time believing that’s the best we can come up with.
Surely there must be a middle ground somewhere between “the application can do anything it wants” and “the application can’t do anything until we’ve spent the next several years teaching SELinux how it works.”
At some point we should be willing to ask whether there is a better way to solve this problem.
I don’t have the answer.
But I’m no longer satisfied with pretending that SELinux is the answer.
David Mulder 