Kitz Forum
Computer Software => Linux => Topic started by: sevenlayermuddle on October 18, 2015, 10:53:16 PM
-
In my ongoing efforts to re-establish a new home server, a common factor is emerging among the small 'nuisances' that kick in just when things ought to work... SELinux, often adding anything from a few minutes to a lot longer to the tail end of each challenge. Not sure about other distros but in CentOS it is enabled by default.
Today I actually gave up, failed to get a subversion server running unless I disabled SELinux, whereupon it runs fine. I could try harder tomorrow and no doubt I would eventually succeed. but I'm reasoning that since I control via my locked down (I hope) home network all access to all services, and it provides no 'public' internet services at all (firewalled by NAT router), why bother?
Not really expecting any answers, just opinions. :)
-
I dont bother with it even on live servers. I have better things to spend my time on than trying to make selinux work properly.
-
I've never bothered with it, but then I don't run any servers either.
-
As is possibly expected, b*cat has to say that he always has SELinux enabled.
Where toggling of the SELinux booleans does not work, an appropriate rule (policy) is created.
Looking in my notes, I find --
Using audit2allow to check the logs:
audit2allow -a
or more thoroughly:
cat /var/log/audit/audit* /var/log/messages* | audit2allow
==================================================================================
Using audit2allow to generate the policy module:
cat /var/log/audit/audit* /var/log/messages* | audit2allow -m local > local.te
Review local.te and customize as desired. Then compile the policy module:
checkmodule -M -m -o local.mod local.te
Create the policy package:
semodule_package -o local.pp -m local.mod
Load the policy package:
semodule -i local.pp
-
As is possibly expected, b*cat has to say that he always has SELinux enabled.
No comment. ;)
But with the encouragement provided I may make a small additional effort tomorrow. Quite apart from any benefits it may convey I, like most people here, just don't like being beaten. Nothing promised though, other than the garden is jungle-like and lawn-mowing will take priority for time available. ::)
Further silence on the topic might be assumed to mean I've admitted defeat.
-
When SELinux is installed on a system it can be in one of three possible operating states --
- Enforcing. All attempts not permitted under the current policy are denied and the attempted violation is logged.
- Permissive. All attempts not permitted under the current policy are allowed and what would be an attempted violation in enforcing mode is logged.
- Disabled. Frowned upon.
The tip, with RHEL (and its clones), is to run the system with SELinux in permissive (rather than enforcing) mode. After a suitable period of time, review the log file and either toggle the relevant SELinux boolean or (if no boolean exists in the curent policy) write your own local policy rule. Then reset SELinux back into enforcing mode.
Here is a CentOS Wiki page on SELinux (https://wiki.centos.org/HowTos/SELinux).
The system from which I am typing this reply shows --
[Duo2 ~]# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 28
Policy from config file: targeted
[Duo2 ~]#
-
Oops. Best I don't post a current copy of my own sysconfig/selinux then. And especially, the comments. :blush:
As promised though, I will try harder. A little.
-
It may be frowned upon but I always disable it as soon as an install is complete. It seems to me to be vastly over engineered for what it does and why you have to jump through all those hoops to create rules is beyond me. In my view it needs to be simplified considerably for normal use, at present in its current state it is a right PITA!
Stuart