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