Today, I spent a couple of hours trying to sort out why a Joomla! Web site, which worked perfectly on my Slackware Linux server, was misbehaving on CentOS 7.
The reason was simple yet complicated. Simple because it was a result of a secure CentOS 7 installation with SELinux (Security Enhanced Linux) fully enabled. Complicated because…
Well, I tried to comprehend some weird behavior. The Apache Web server, for instance, was able to read some files but not others; even when the files in question were identical in content and had (seemingly) identical permissions.
Of course part of it was my inexperience: I do not usually manage SELinux hosts. So I was searching for answers online. But this is where the experience turned really alarming.
You see, almost all the “solutions” that I came across advocated severely weakening SELinux or disabling it altogether.
Since I was really not inclined to do either on a host that I do not own, I did not give up until I found the proper solution. Nonetheless, it made me wonder about the usefulness of overly complicated security models like SELinux or the advanced ACLs of Windows.
These security solutions were designed by experts and expert committees. I have no reason to believe that they are not technically excellent. But security has two sides: it’s as much about technology as it is about people. People that include impatient users and inadequately trained or simply overworked system administrators.
System administrators who often “solve” a problem by disabling security altogether, rather than act as I have, research the problem, and not do anything until they fully understand the issue and the most appropriate solution.
The simple user/group/world security model of UNIX systems may lack flexibility but it is easy to conceptualize and for which it is easy to develop a good intuition. Few competent administrators would ever consider solving an access control problem by suggesting the use of 0777 as the default permission for all affected files and folders. (OK, I have seen a few who advocated just that, but I would not call these folks “competent.”)
A complex security model like SELinux, however, is difficult to learn and comprehend fully. Cryptic error messages only confound users and administrators alike. So we should not be surprised when administrators take the easy way out. Which, in a situation similar to mine, often means disabling the enhanced security features altogether. Unless their managers are themselves well trained and security conscious, they will even praise the administrator who comes up with such a quick “solution”. After all, security never helps anyone solve their problems; by its nature, it becomes visible only for its absence, and only when your systems are under attack. By then, it’s obviously too late of course.
So the next time you set up a system with proper security, think about the consequences of implementing a security model that is too complex and non-intuitive. And keep in mind that what you are securing is not merely a bunch of networked computers; people are very much part of the system, too. The security technology that is used must be compatible with both the hardware and the humans operating the hardware. A technically inferior solution that is more likely to be used and implemented properly by users and administrators beats a technically superior solution that users and administrators routinely work around to accomplish their daily tasks.
In short… sometimes, less is more indeed.