{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreih7huzhzafzibysaup5bzbwkg6pza3f24nrtkdqqkjcea6bflqnfe",
    "uri": "at://did:plc:3pjw65epwlo3rzajhx6xg4br/app.bsky.feed.post/3mnivgysnbw52"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiacfojcilwlxojxabxxa2vyjkmnhk2tigpzwlhw4sutj2boysy5we"
    },
    "mimeType": "image/png",
    "size": 47009
  },
  "path": "/2026/06/04/selinux-insanity-doing-the-same-thing-over-and-over-and-expecting-security-convergence/",
  "publishedAt": "2026-06-04T21:33:22.000Z",
  "site": "https://mytechinsights.wordpress.com",
  "textContent": "**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?**\n\nThere is one thing in open source software that consistently consumes more time than it has any right to.\n\nSELinux.\n\nEvery few weeks it seems like another SELinux issue appears.\n\nImplementing a new feature? Fix SELinux. Fixing a bug? Fix SELinux. Scratching your butt? Gotta fix your SELinux policy. Repeat forever.\n\nAt some point we should start asking the question: What exactly is this accomplishing?\n\n## The Concept\n\nThe 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.\n\nThat’s a reasonable goal.\n\nI’m not arguing against the idea of mandatory access control. I’m questioning whether this was the right tradeoff.\n\n## The Cost of Convergence\n\nIf 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.\n\nBut what a ridiculous way to get there.\n\nThe model seems to be: run the software, wait for SELinux to break something, examine the denial, add a rule, repeat until users stop complaining.\n\nThat’s not design. That’s playing whac-a-mole.\n\nWe’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.\n\n## An Engineering Failure\n\nSELinux 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.\n\nSurely 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.”\n\nAt some point we should be willing to ask whether there is a better way to solve this problem.\n\nI don’t have the answer.\n\nBut I’m no longer satisfied with pretending that SELinux is the answer.",
  "title": "SELinux Insanity: Doing the same thing over-and-over and expecting security convergence"
}