Does SELinux make Redhat more secure?

Solution 1:

Yes, Selinux makes system more secure. But you'll need to undestand concepts of it and have at least basic knowledge about selinux and audit tools.

Selinux is logging to /var/log/audit/audit.log (but ensure auditd is running), and there are number of tools to solve selinux problems. Probably simplest way is to use is audit2allow

Solution 2:

Yes, SELinux makes Red Hat (and any other Linux distribution that actually uses it) more secure, assuming it's actually in use.

SELinux implements mandatory access control. Normal Unix permissions, ACLs, etc., implement discretionary access control. The two complement each other.

In order to work, SELinux requires a policy, defining what actions on the system may be allowed. While it's possible to create an entire system policy from scratch, most Linux distributions ship a policy based on the so-called reference policy. This means, among other things, that configuring SELinux across distributions will be very similar. (Most Linux distributions make the SELinux reference policy available in their package repositories, though it may not be installed by default.)

SELinux works by restricting users and processes to perform only the actions allowed to them in the policy. By default, the policy is to deny, so if the policy doesn't explicitly allow an action, then it doesn't happen. This is why you so often run into trouble with SELinux disallowing something you're trying to do.

On the bright side, this also prevents exploits, even 0-day exploits, from getting out of hand. For instance, if your web server (Apache) gets exploited, the damage is limited to only those things that Apache can access. It wouldn't be able to read your /etc/shadow file, for instance, even with a remote root exploit. While the Unix permissions (DAC) permit root to read the file, SELinux (MAC) does not permit the compromised process to step out of bounds.

The big gotcha is that there must be an SELinux policy module loaded for the service. If you install a service on your box which doesn't include an SELinux policy module, then it will run unconfined and be able to do whatever it wants. SELinux won't apply to it.

Another thing you should know is all about booleans. These tunable parameters are provided by SELinux policies to customize them for particular installations, and permit or deny access based on local configuration needs. For instance, you can give Apache access to Samba shares, enable Samba to share user home directories, and many other potentially useful things which are necessary for some setups but not others.

The best guide to SELinux that I've seen currently is Red Hat's Security-Enhanced Linux User Guide. It will help you get up and running quickly as well as fill in the background details of what's going on. It also includes a comprehensive troubleshooting guide that helps you get your process running under SELinux.

Is it useful?

SELinux protects against processes (and users, if you've confined your users) doing unexpected things. It severely limits the damage that a remote exploit can do. If you've never suffered a remote compromise, you are (1) fortunate, and (2) probably new. If you have worked a remote compromise, you certainly don't want it to ever happen again.

It's not as useful in a home setting, unless you happen to be running Internet-facing services at home (and some people do). In that case, everything said above applies.

SELinux may be the last thing that stands between your data and an attacker with a 0-day exploit who really wants it. If you can use it, why wouldn't you?