On 01/07/16 16:05, James M. Pulver wrote: [...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) >> >> Disabling SELinux is in 2016 *not* a solution and can barely be >> considered a workaround. [...snip...] >> </rant> >> > We always disable SELinux. Makes life much better IMO. Pretty much all > our commercial software starts with "Disable SELinux", and the time I > tried to enable it (well, it was enabled by default) on a SL7.1 home > desktop I didn't get 1 day into setting up things until it just blocked > something. In my case it was READ ACCESS to an OpenVPN cert in my home > directory. I was running OpenVPN at the time via the GUI under my user. > So I disabled it so I could actually use my PC.
Regarding OpenVPN ... Put your certificates in $HOME/.cert/ ... you might need to relabel your files in that directory though (restorecon -rv $HOME/.cert/). But with that in place, OpenVPN will be allowed to access your certificates in your $HOME. Yes, a lot of commercial software are giving bad advices. Mostly I've ignored those "disable SELinux" instructions, and it still works quite well. And if there are any issues, my experience is that putting the system into Permissive mode (setenforce 0) run the application for a little while and then run audit2allow against log entries in /var/log/audit/audit.log resolves most of the issues. With the new SELinux module loaded, I can switch back to Enforced mode (setenforce 1) without any issues. Remember that the default for any process not having an explicit context mode written for it will always run as the unconfined_t context type which have very little limitations. Running audit2allow as described above will *not* confine that application/process in its own context type; it will only allow the process to do things the system defaults in the unconfined_t security context would block. To write your own policy properly confining a process in its own security context requires more work. [...snip....] > Honestly, SELinux is something I'd like to use, but I think someone > needs to make it like Comodo Internet Security HIPS on Windows - a GUI > running as root, or preferentially given permissions some how - that > pops up when SELinux is going to block something and lets you click > "Allow / Deny / Terminate program" with a checkbox "remember my answer". > Right now the barrier to use is too high when you can simply turn it > off. It's the same reason we disable UAC in Windows. Ensure you are running setroubleshoot, then you do get a GUI alert each time a SELinux denial happens. You can't currently kill the process from setroubleshoot, but it usually guides you how to avoid this from happening again if you want to allow that operation. I'm not saying setroubleshoot is the best tool there is, but it gives you quickly a heads up. Otherwise, I recommend paying attention to Dan Walsh. He does a lot of presentations on conferences (many are recorded and can be found on YouTube) and he posts regularly on his blog [1] about SELinux. [1] <http://danwalsh.livejournal.com/> And as a teaser, I know there are work in process in making the SELinux better - also in performance but making it easier to write the policies using a simpler policy langague. AFAIK, most of these changes are already in Fedora, so I'd be surprised if we won't see them in a future RHEL 8. <https://www.youtube.com/watch?v=JpfgPteHc-Q> And for a simple SELinux introduction ... <https://github.com/mairin/selinux-coloring-book/raw/master/Print-Ready/Web.pdf> -- kind regards, David Sommerseth
