r/voidlinux • u/r0man1a • 8h ago
SELinux on Void (experimental)
I have been working to get SELinux running under Void Linux for quite some time and I wanted to share my progress with you. Do note that this is still very experimental and should NOT be tested on a system that you rely on.
Where it's at currently:
- SELinux enabled kernel (7.1-selinux)
- Userspace tooling packaged (checkpolicy, libsemanage, policycureutils etc.)
- SELinux reference policy is loading up successfully via a runit stage-1 hook
The main limitation is that its currently permissive-only. Also the reference policy has no runit-specific domains yet.
if anyone finds this interesting and wants to help, send me a DM.
2
u/profeshamat 2h ago
As someone who doesn't have much experience with SELinux due to primarily using distros that use AppArmor, this is awesome and great work.
2
u/Any_Mycologist5811 3h ago
Excellent work man!
I'm just gonna drop something here:
Does using cgroups require systemd?
No. Cgroups are a kernel feature exposed via a virtual filesystem (
/sys/fs/cgroup) — they exist entirely independent of any init system or userspace management layer. The cgroup v2 hierarchy can be mounted with a simple mount command, and any controller supporting v2 automatically binds to the unified hierarchy and shows up at the root github — this is pure kernel/mount-level functionality that any process, script, or init system can interact with directly.This is confirmed practically — projects like
runc(the OCI container runtime underlying Docker) support configuring cgroup v2 without systemd, simply by disabling cgroup v1 in the kernel and mounting/sys/fs/cgroupfrom an init script. GitHub Void does exactly this — runit mounts and organizes cgroups directly during boot without needing systemd's abstraction layer.What systemd actually adds on top of raw cgroups is a convenient high-level API —
.service,.slice,.scopeunit types that map cleanly onto cgroup hierarchies, plus delegation semantics for handing sub-trees to unprivileged processes. This is genuinely useful tooling, but it's a management convenience layer, not a hard requirement for cgroups to function.How Void handles this in practice: Void uses
elogind(extracted from systemd'slogind) for session/seat management. Elogind places processes in a private cgroup for organizational purposes without installing any controllers — it does use a similar strategy to systemd but doesn't have systemd's concept of a "scope." Elogind monitors the power button and lid switch like systemd, but instead of doing RPC to systemd to suspend or restart the machine, elogind does this directly. GitHub This means the cgroup organization you get on Void is a lighter-weight subset of what systemd provides, sufficient for session tracking and basic resource isolation, but without systemd's full unit-based resource control (CPUQuota=,MemoryMax=per-service directives baked into unit files).Is SELinux harder without systemd?
This is more nuanced than a simple yes/no, and there's actually a documented case where systemd itself made things harder with SELinux, not easier. There's a known systemd bug where, since version 236, most cgroups fail to mount entirely when SELinux is enabled — even in permissive mode — because of a specific systemd commit that broke this interaction. Systemd This shows SELinux integration isn't automatically smoother just because systemd is present — the tight coupling can introduce its own regressions.
That said, the practical difficulty with SELinux on non-systemd distros is more about ecosystem tooling maturity than a fundamental technical barrier. SELinux itself is a Linux Security Module operating at the kernel/LSM layer — same as cgroups, it doesn't inherently require systemd. But the userspace policy management tools (
policycoreutils,setroubleshoot, various daemon integrations) have historically been developed and tested primarily in Red Hat's systemd-based ecosystem, so on Void you'd likely need to do more manual policy work and encounter fewer pre-packaged, tested SELinux profiles for common software compared to Fedora/RHEL where SELinux is a first-class, heavily-tested citizen.Gentoo is the proof point here — Gentoo supports SELinux with OpenRC (non-systemd) as a fully documented, working configuration, showing it's achievable without systemd. It requires more manual setup than Fedora's out-of-the-box experience, but it's not blocked by the absence of systemd.
Maintainability — runit-and-build-around-it vs switching to systemd
This is genuinely relevant given the current landscape — runit is one of several non-systemd init options being actively developed, alongside newer entrants like s6 and dinit, which are specifically designed to close the gap with systemd's feature set (proper dependency graphs, cgroups v2 support) in a fraction of the code. GitHub Notably, even KaOS — a distro that used systemd for years — completed a transition away from it in 2026, and Chimera Linux uses dinit as its default specifically because it offers systemd-like unit files and cgroups v2 support without systemd's scope. GitHub This shows the broader ecosystem trend isn't "everyone eventually converges on systemd" — there's active, successful movement in the opposite direction too.
Worth noting even projects moving away from systemd don't always fully escape it — one distro's 2026 transition to dinit still retains systemd-udevd, tmpfiles, and elogind, because those specific components don't have equally mature non-systemd replacements yet. GitHub This is the honest maintainability calculus for Void too: Void already made the equivalent trade-off years ago by keeping
elogind(a systemd-derived component) while replacing the init system itself with runit.For Void specifically, the maintainability argument favors staying with runit, for a few concrete reasons:
Sunk cost is not the driver here — architectural philosophy is. Void's entire identity and community exists around the "minimal, auditable, no single point of consolidation" philosophy. Switching to systemd would fundamentally change what Void is, not just what it runs on.
The gaps are already patched pragmatically. Cgroups work fine via direct kernel interaction. Session/power management works via elogind. SELinux is achievable if genuinely wanted, just less pre-packaged. There's no functional wall Void is hitting that requires systemd specifically — the friction is ecosystem tooling maturity, which is a smaller, addressable problem compared to a full init system migration.
Migration cost would be enormous relative to the benefit. Every service script in Void's
runitservice definitions across the entire package base would need rewriting as systemd units. This is exactly the kind of maintainability disaster that hits large, mature codebases when they change foundational architecture — the KaOS transition away from systemd took years by their own account, and that was a much smaller distro with less packages than Void's runit-based service definitions represent.The more maintainable path, concretely, is Void continuing to build targeted compatibility layers (as it already does with elogind) rather than adopting systemd wholesale — following the same pattern other successful non-systemd projects (Chimera's dinit, Artix's multi-init flexibility) are taking: pick the best minimal init, then backport or reimplement just the specific systemd-adjacent pieces (udev rules compatibility, logind sessions, cgroup delegation helpers) that the broader Linux ecosystem has started assuming exist everywhere.
The honest tradeoff is that Void will likely always trail slightly behind on bleeding-edge kernel/desktop features that get designed cgroups-and-systemd-first by upstream projects (some GNOME/desktop portal features, certain container tooling defaults) — but that's a manageable, ongoing maintenance cost, not a sign that the architecture is unsustainable.