The Internet looks more like a combat zone every day. I have had four six different credit card numbers stolen from various servers. One way to prevent this kind of hacking is to harden your server. A good way to harden a server is to run SELinux in enforcing mode. When you install recent releases of Fedora it automatically turns on SELinux enforcing as a standard part of the installation.

SELinux works by examining calls to the Linux kernel made by every running program. It tests each call against a set of rules called a policy. If a call to the kernel violates one of these policy rules, the call is blocked and an error message describing an "AVC denial" is sent to the system administrator. Often, the administrator will puzzle over the message for a few minutes then find a way to turn off SELinux enforcement. Doing so reduces the system's defenses against hackers.

A wise administrator takes the time to learn enough about SELinux to take advantage of its protection. The video embedded below is a good place to start. After you learn basic SELinux skills, you can proceed to work on real world security tradeoffs. Security is always a tradeoff, because it is difficult to build a system that keeps the bad guys out without interfering with legitimate use of the system. I've noticed that if one door in a corridor has a high-security lock protecting something that people use a lot, there is often a wastebasket propping that door open.

Here is a good practical example of such a tradeoff. It affects Drupal and any other Internet-connected software that uses recent releases of the PCRE library. Evaluating a regular expression in PHP by default causes an AVC denial:

The source process: php-fpm
Attempted this access: execmem

What has happened here is that the PCRE JIT compiler has compiled a regular expression onto the stack, and then tried to execute it from the stack. SELinux has a policy rule forbidding execution from the stack. There is a good reason for this rule. A common way to hack into a system is to store some data which has malicious code embedded onto the stack, then execute the malicious code. The AVC denial message then goes on to explain how to stop enforcing this rule. Think carefully about the alternatives and tradeoffs before you turn off the rule.

The PCRE library JIT compiler stores and executes code on the stack as a way to speed up execution. Instead of turning off the rule, an alternative is to turn off the JIT compiler stack execution feature by editing the php.ini file to say pcre.jit = 0. This takes away the vulnerability at the cost of slower execution. So you must think seriously about the tradeoff: faster execution but vulnerable, or slower execution and less vulnerable.