Why do we need SELinux?

I could not get much idea where the SELinux has been used and what it saves from attacker. I have gone through SELinux web site and read the basic but still not getting clue about SELinux. For the Linux system which provides the SSH shell, Apache front end, role based web application, MySQL DB, memcached, almost all the systems are password protected, then why do we need SELinux?


Solution 1:

You may view SELinux as a system-call firewall: A policy for each application specifies what's reasonable for the application to do: The name server may listen on port 53, work with some zone files in a particular directory, send out syslog, ..., but it makes no sense for it to try to work with files in /home, for example. SELinux' enforcement of such a policy means that it will be much harder for a weakness in the name server to spread to other parts of the system.

I find that SELinux provides real security value. But while it has certainly become easier to work with over the years, it is - unfortunately - still a rather complex system. The good thing is that you may easily turn it off for some services, without having to turn it off for the whole system. Too many (junior?) sysadmins turn of SELinux across the board, as soon as they run into the slightest problem with one service - instead of selectively turning it off for the service causing trouble.

Solution 2:

Not all security issues can be predicted in advance. If an attacker manages to exploit a weakness in e.g. a third-party httpd module then they have access to the same files that the user httpd is running as does. SELinux further restricts this by limiting them to actions and file contexts that their SELinux domain has access to.

Solution 3:

These previous questions might be informative:

SELinux in the Real World

and

Real life SELinux security example?

and

Reasons to disable / enable SELinux

Solution 4:

I think the term Mandatory Access Control sums it up quite nicely. SELinux gives you a more secure system through a more secure kernel, in large part due to a MAC implementation.