On 30/06/16 07:23, Nico Kadel-Garcia wrote: > On Wed, Jun 29, 2016 at 6:12 AM, David Sommerseth [...snip...] >> 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.
I fail to see that being an SELinux issue. That's merely an issue with the ISV ignoring SELinux. If ISVs just plain ignore SELinux, can you then trust they take security seriously? Regardless, in these cases the monkey should be put on the ISV's shoulder. This basically is the same situation as older Windows applications failing to run because it expected the end user to have admin privileges while there would be no real reason for such a need. [...snip...] >> 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. If you use standardized file paths for storing/accessing files, these issues are seldom an issue if you're using the targeted SELinux profile. By default software not having an explicit SELinux policy will run as unconfined_t, which means SELinux normally would not be an obstacle. There are however some limitations to some files/directories where the security impact is too high. IIRC, /etc/shadow is one of those files which have such an extra security check. To put together a new SELinux profile might be easy or it might be hard, it all depends on how complex your package is and how tight you want the security around it. >> 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. Fully agree! However, running in permissive mode might fill your logs quicker if you have a lot of denials. -- kind regards, David Sommerseth
