[Discuss] apache problem

[cra at wpi.edu (Anderson, Charles R)]

On Wed, Jan 09, 2019 at 01:42:08PM -0500, Rich Pieri wrote:
> 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.

Neither does "chmod -R a+rwx /" or running everything as root grant
anyone any access if they don't have a login to the system.  Do you
recommend everyone should do that (or perhaps "chmod -R 777
~/public_html" which was a common meme on internet forums years ago)
because it is "easier" than trying to learn these "hard to use and
confusing chmod 755 644 thingies".

> 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.

Yes, MAC is more strict and provides more compartmentalization than
DAC.  It is useful for way more than just the US government.

> 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

It can harden a system against attack from without for example by
preventing sockets from being bound, similar to iptables.  But most of
what it does is limit the scope or capabilities of an attack once
outer defenses are penetrated, and also can provide alerting to an
attack.  Defense-in-depth.

There is already a rich set of access controls defined for the SELinux
targeted policy that most people use, and is the default
out-of-the-box config on Fedora and Red Hat.  So you get to benefit
from all that work with very little effort.

DAC & iptables are also enforced by the kernel, so your argument about
SELinux not preventing attackers from attacking the kernel is moot if
we are comparing various security technologies in the kernel.
Additionally, if someone were to successfully attack iptables for
example, it is possible that SELinux could prevent the attack by
providing an additional layer of defense.  Note I said "possible" not
"guaranteed".

> > 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.

Of course you can find examples where SELinux didn't help.  That
doesn't mean there aren't examles where it did help.

> 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.

Well, I did say Google, because that is what I checked, not DuckDuckGo.

https://www.linuxjournal.com/article/9176

https://rhelblog.redhat.com/2017/01/13/selinux-mitigates-container-vulnerability/

https://access.redhat.com/blogs/766093/posts/3557091

https://danwalsh.livejournal.com/10131.html

and specifically for Shellshock:

https://cybermatters.info/2014/10/09/shellshock-selinux/