[Discuss] apache problem

[richard.pieri at gmail.com (Rich Pieri)]

On Wed, 9 Jan 2019 17:45:55 +0000
"Anderson, Charles R" <cra at wpi.edu> wrote:

> Over the years some misinformed people have suggested "fixing"
> permissions by doing this (or variations), but it is not recommended:
> 
> chmod -R a+rwx /
> 
> Disabling SELinux is in the same vein.

Crap. Disabling SELinux does not grant anyone, never mind everyone,
full read and write access to every file and device on the system. To
suggest that these are at all similar is blatant FUD.

Here's my counter-argument: SELinux does not do what you think it does.

SELinux provides mandatory access control (MAC) to resources. This is
saying something like "Apache has access to this network interface and
files in these directories". The security it provides is compartmenting
resources for organizations like US government agencies which require
access controls more strict than POSIX provides.

It does not harden a system against attack from without. It does not
prevent attackers from attacking a system. It can make exploiting
certain categories of bugs more difficult but this is dependent on the
access control rules you have defined and not SELinux itself (such
exploits can be better and more easily compartmented and mitigated at
the infrastructure level so SELinux is not needed for this). It does
not prevent attackers from attacking the kernel and this is the
priority target for any serious attacker.


> Search google for "selinux prevented exploits" to see examples.

The first hit on duckduckgo is a link to a reddit thread about fi01's
put_user() exploit which is not prevented by SELinux.

The second hit is a link to a ycombinator discussion about how SELinux
does not prevent or contain bashdoor/shellshock exploits with a side
note about how SELinux does not prevent or contain Heartbleed exploits,
either.

Number 3 is an article about how SELinux can be configured to detect
and contain some categories of remote code execution exploits.

Number 4 is a link to a youtube video demonstrating an old kernel
vulnerability exploited to disable SELinux.

Five is some documentation at Red Hat about SELinux.

Six is a blog article about SELinux being able to contain a Samba
exploit that had never been exploited. Which was more than 10 years ago.

I stopped reading at this point because I'm just not finding anything
to suggest that SELinux is as great and wonderful as you seem to think
it is.

-- 
Rich Pieri