<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Selinux - vo.rs</title><link>https://vo.rs/tags/selinux/</link><description>Latest from the Selinux desk at vo.rs.</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright><lastBuildDate>Tue, 22 Oct 2024 10:00:00 +0000</lastBuildDate><atom:link href="https://vo.rs/tags/selinux/" rel="self" type="application/rss+xml"/><item><title>SELinux Without Turning It Off</title><link>https://vo.rs/story/selinux-without-turning-it-off/</link><description>&lt;p&gt;Every homelab has a moment where a service refuses to start, the logs are useless, and &lt;code&gt;setenforce 0&lt;/code&gt; is sitting right there in your shell history from the last time this happened. I&amp;rsquo;ve typed it more times than I&amp;rsquo;d like to admit. It fixes the immediate problem the way unplugging a smoke alarm fixes a burning pan — technically true, and a bad habit to build.&lt;/p&gt;
&lt;p&gt;SELinux gets a reputation as the thing you disable during setup, right after you set a root password you&amp;rsquo;ll forget. That reputation is earned by tooling that used to be genuinely hostile to newcomers, but it&amp;rsquo;s stale. Modern SELinux on Fedora, RHEL, Rocky and Alma ships with tools that turn &amp;ldquo;why won&amp;rsquo;t this start&amp;rdquo; into a five-minute diagnosis, and once you&amp;rsquo;ve done it a few times it stops being scary. This post is the workflow I actually use: read the denial, understand why it happened, and either fix the context or write a scoped policy module — never reach for the global off switch.&lt;/p&gt;</description><pubDate>Tue, 22 Oct 2024 10:00:00 +0000</pubDate></item></channel></rss>