Stephen Gallagher writes:
So it appears to be an SELinux issue. I suspect but cannot prove that it's related to a number of AVCs related to DBUS that I see in selinux-troubleshooter.
I've watched SELinux come into existence, and its evolution over the years.It's clear to me that SELinux, let's say diplomatically, hasn't lived up to its expectations. The expectations in questions would be: it has an established mindshare; and software package maintainers can easily write, have clear documentation to follow, and ship selinux policies for their packages.
Has this been happening? Of course not. Can anyone ever see this happening? Nope.
Instead what we have now is siloed selinux package maintainance, with the selinux package responsible for constantly revising and updating a SYSTEMWIDE security policy, covering ALL packages in the distribution, in addition to popular software packages that are often installed, but not a part of the core distribution.
Does this state of affair seem logical to anyone?SELinux maintainers can't be expected to be familiar what each and every package does, and constantly stay up to date with any updates in this area.
This situation will never improve. Stuff will continue to break, with selinux. It will have to be constantly fixed. Hopefully. If it can be fixed in the first place.
A more sensible approach would be for individual package developers and maintainers install their package's selinux policy together with the package, and maintain it. That makes too much sense, doesn't it?
But it will never happen. Maybe my Google skills are rusty. Maybe my brain has atrophied. But I don't see, speaking very generally, how can anyone can avoid pouring a massive amount of time into figuring out how to write an SELinux policy for a package whose inner workings they can understand.
SELinux's policy file syntax is unlike any other syntax of any other configuration system I know off. I searched, but could not find any tutorial or any sort of a guide to writing SELinux policies, or explain what /any/ of the cryptic statements in the existing selinux policy files do.
Are you a package maintainer? Ok: please write an selinux policy for your package. Let me know when that's done.
If one wants to learn how to write an rpm spec file, one can actually find useful documentation, even entire books on it. Although some of the info there is somewhat outdated, it's more than enough to get started, and learn enough to be able to figure out the missing pieces.
Can someone post a link to the SELinux equivalent to the "Maximum RPM" book?Nobody was surprised more than me when I was able to cobble together an selinux policy file from scratch that allowed me to install and run my library, with a network server daemon. But it took over a week. It should've taken five minutes. That's what it actually took to physically type it. But it took over a week of frantic digging all over every corner of the intertubes, and countless cycles of "enable enforcing, wait until something breaks, look at the AVC message, grep the existing policy files for something that seems to define the capabilities that are missing, add them the policy file, recompile and reinstall it. This is not a practical way of implementing an SELinux policy.
Only Fedora, IIRC, has selinux enabled by default. None of the other distributions have it turned on out of the box. Maybe someday SELinux has ample documentation, and is easy to configure and set up, for a given package, by the package's maintainers with just a minimal learning effort. Maybe someday there will no longer be a need to have a dedicated team of gurus who are the only ones that really know how it work, in order to support it. Until such day arrives Fedora will continue to be dragged down, and hobbled by having to have SELinux enabled by default.
Attachment:
pgpcEdOklQr_Z.pgp
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
