[Discuss] apache problem

[invalid at pizzashack.org (Derek Martin)]

On Wed, Jan 09, 2019 at 05:45:55PM +0000, Anderson, Charles R wrote:
> On Wed, Jan 09, 2019 at 10:49:51AM -0600, Derek Martin wrote:
> > On Tue, Jan 08, 2019 at 06:44:59PM -0500, James Cassell wrote:
> > > Please don't disable SELinux.
> > 
> > Why?  Can you make a compelling case?
> 
> I'll try.
> 
> 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.

I think it's not at all the same though.  SELinux is an *additional*
security measure that sits on top of, and somewhat depends on, all the
other Unix/Linux security mechanisms being properly configured and
intact.  For instance, if, on your system, everyone just logs in as
root, or otherwise has certain capabilties (in the kernel sense of the
term), then anyone can modify SELinux contexts/roles/levels
willy-nilly and effectively render it impotent.

> > [I'm also largely of the opinion that if your system is otherwise
> > secure, extended ACLs of any sort are unnecessary, and Unix
> > permissions suffice just about always, excepting cases when you have a
> > very large number of users with a very large number of disparate
> > access needs to resources. And usually, even then.]
> 
> Well, if your system is so secure, no one else logs in, and you don't
> have any kind of shared-tenancy, you don't need file permissions
> either and you could just always log in as root and run all servers as
> root, but again none of this is recommended.  Because no system is
> totally secure.  Defense-in-depth is why we have and use separate
> login/service accounts, standard Unix permissions (Discretionary
> Access Control), and SELinux (Mandatory Access Control).  It is for
> when something unexpected happens, like a new 0-day exploit is
> discovered in Apache and you don't patch it in time.

I'm a former SANS-certified network/security/system admin, I know
what defense in depth is.

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

Sure.  The first example was an attack against Mambo, a web-based
content management system.  If you're running a service like this and
allowing it to be directly routable to the Internet, you're not
practicing defense in depth.  If you were, you'd have this service
behind a firewall that's behind your DMZ (behind another firewall),
requiring your users to be physically present on your network, or VPN
into it.  Or something of the sort.  If so, then EITHER these attacks
never would have made it to your Mambo server, OR you have a much
bigger problem, for which SELinux may not necessarily help you.

These attacks may well have been stopped by SELinux, but this does not
preclude the possibility that they could easily have been stopped by
other, much simpler to configure and maintain measures that did not
require SELinux to be active on the system.

Part of my concern with SELinux is its complexity.  Complexity is the
enemy of reliability.  The harder it is to configure and maintain, the
more likely it will be that you will botch it, to your great
detriment.  SELinux is effectively just another set of ACLs that sits
on top of all the other layers of ACLs that Linux already has, but
which are much easier (less complex) to manage.  In combination with
reasonable access policies, proper configurations, and regular
patching--all of which you need anyway--I've not found cases where
these things couldn't save you from anything that SELinux would have.  
As such, I find that not using it actually improves security,
particularly in cases where you do not need extremely high levels of
security.  And most of the folks here, let's be honest, just don't.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.