SELinux and Logs
What is the SELinux?
Some of the most frustrating but rewarding feelings come from those “a-ha!” moments. One of my favorite sayings is that your only difficult problems are the ones you are currently facing, as you already have solutions for resolved problems. Let me tell you about my “a-ha!” moments with SELinux, and how I’ve started to love documentation.
As a brief summary, SELinux is “a mandatory access control (MAC) security mechanism implemented in the kernel” developed and maintained by the https://wiki.centos.org/HowTos/SELinux. To me, the easiest way to explain SELinux is to either compare it to a modern smart phone’s app system, or to the more technically savvy, BSD jails or Windows containers. SELinux allows granular control an application’s privilege level on a process by process level. This is important for servers where you really have a general idea for what should be running. And if malicious code were to appear on the server from something like a zero day exploit, it would be implicitly denied from executing.
This is comparable to smart phones in that all applications are kind of in their own ecosystem. When you uninstall an application, everything in that “jail” is removed. This concept mirrors BSD jails and Microsoft’s newly touted “containers” they are releasing in Windows Server 2016. But the idea has been around since Citrix tried to implement the system in the 1990’s.
What is the goal?
To back pedal a little, let me explain what I hope to accomplish in this little series. Throughout the years, I had a bad tendency of collecting Linux servers on a VPS. Whenever I needed to add a website or another dedicated service, it was actually more economical to just spin up another 5 dollars a month host. But I started to face a problem: there was a significant amount of underutilized hosts and they were not standardized at all. I had hosts that were properly locked down while others where just thrown up in a matter of minutes. I hope to combat this with one master LEMP stack that is set up with the works from the get-go: to list a few, I want Snort, SELinux, Splunk, and generally just a more mature setup. I also want redundancy by sending syslogs into an independent host.My goal is to do a mini write-up of the particularly difficult processes and hopefully in the process I’ll be able to articulate what each process does in the future.
First up is SELinux. SELinux has been a thorn in my side for a while. I really want to like it, and I certainly applaud the verbosity of the logging, but it really seems like the wild west when it comes to documentation (and everyone has their own pet theories about why. However, most of the theories involve tin foil hats and poison pills). For me, it is very difficult to get even a base understanding about how to implement policy. The majority of documents I see for other projects just flat out state to just disable SELinux to have their project play nice with the host. For example, this was taken from the https://wiki.mumble.info/wiki/Install_CentOS.
Note: The steps outlined here will probably make security folks cringe. If anyone has the time and patience to figure out SELinux, please consider updating this document with a proper solution.
SELinux by default will prevent murmur from functioning correctly. The quick and easy solution is to simply disable it. To disable temporarily (until the next reboot), run:
sudo setenforce 0
To disable permanently (after the next reboot), edit '/etc/sysconfig/selinux' and change the "SELINUX" line to:
SELINUX=disabled
So here lies the problem: SELinux is an incredibly powerful kernel security module that offers an insane amount of verbose logging and will prevent a large amount of zero day exploits, but nobody utilizes it.
What are you going to do about it?
Good question! I am by no means an expert in anything I do, computer or otherwise. However, I’m going to write about some of my findings in a “rolling release” manner. I really don’t expect to be writing anything here that will blow people away, but I want to be documenting my findings and hopefully in the process, start to understand SELinux a bit better.
So one of the biggest troubles in creating the master LEMP stack, DRE, was when it was silently denying connections to my log server EAZY-E. Yes, I am naming my server hostnames after the rap group NWA. Something I really need to get better about is marking down where I left off in order to identify difficulties in a more timely fashion. After banging my head against a wall after repeatedly picking up the project for short amounts of time, I realized that the root cause was that rsyslog was configured incorrectly. I forgot I had SELinux enabled, and after checking my recent SELinux logs using the following command, I received an odd response:
ausearch -m avc --start recent
avc: denied { name<em>connect } for pid=25444 comm=72733A6D61696E20513A526567 dest=20514 scontext=system</em>u:system<em>r:syslogd</em>t:s0 tcontext=system<em>u:object</em>r:unreserved<em>port</em>t:s0 tclass=tcp_socket
For the eagle eye’d among you, you’ll notice that rsyslog was trying to send via TCP port 20514. I wanted to use port 514 and apparently accidentally added an extra “20” at the beginning of the desired “514”. I was trying to figure that one out for a little over a couple of weeks before I checked to see if SELinux was enforcing policy. In addition to SELinux blocking the unregistered port, the firewall would have done so also. I can’t tell you how silly I felt.
Summary
So this is more of a moving target for me. I don’t really have a desired “end goal” to this post, but I certainly plan to update as I move on. Hopefully someone found something useful in this block of text. My main take away from these problems would be that I need to write down where I leave off and that I need to respect the power of SELinux.
