On Wed, Jun 29, 2016 at 6:12 AM, David Sommerseth <[email protected]> wrote: > On 29/06/16 10:00, Bill Maidment wrote: >> My final attempt was successful, sort of. >> I switched SElinux to enabled and rebooted, then the install worked OK. >> Then I had to use a live CD to be able to boot, changed SElinux to disabled, >> and reboot again. >> Then I had to us lpoptions to set the default parameters as the CUPS gui >> tool refused to change anything. >> Phew. What a tortuous route. >> Back to sleep now......... > > <rant> > > Let this be an example why NOT to disable SELinux. SELinux has been (if > my memory serves me right) available since Fedora 6 (released in 2006) > and RHEL *4*! I believe it was turned on by default in Fedora 8 and > RHEL 5. And in RHEL 6 you could no longer disable SELinux at install time.
It's a reason to set it to "permissive" and check the logs. And yes, SELinux remains a problem with locally developed, thirdparty, and even default upstream software. I'm afraid the amount of time wasted debugging it frequently even usually, outweighs the security benefits. > SELinux is not the obstacle it once was over a decade ago. So if you > have issues when it is enabled, learn to use the proper tools to debug > and fix it correctly. (audit2why, audit2allow, semanage, restorecon, > etc, etc) Until and unless you use something that is not from an RHEL or Scientific Linux published RPM that has gone through real QA. > Disabling SELinux is in 2016 *not* a solution and can barely be > considered a workaround. > > Refusing to to use, accept and learn SELinux will serve you no good in > the long run. See above. Security is a trade-off between trouble saved by having security, and caused by the security itself. > Seriously, I've been running a various amount of Fedora, RHEL/SL/CentOS > installations and versions over the last 8-9 years. In SL7 SELinux have > not bitten me much at all (only one issue with logrotate on servers > running Zimbra Collaboration Suite, that's all). I have the last 6-7 > years never needed to disable SELinux to accomplish my tasks. Yes, I've > put systems into permissive modes to see if SELinux was to blame, but > mostly that was not the issue. It's gotten better. As soon as you start hand-compiling servers for development reasons, or start writing your own RPM's, it starts costing serious engineering time. > So if you are badly hit by SELinux troubles, you need to look into if > you or the software you use are doing the right things. > > </rant> Permissive is your friend. Disabled can cause its own problems.
