[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] apache problem
- Subject: [Discuss] apache problem
- From: invalid at pizzashack.org (Derek Martin)
- Date: Wed, 9 Jan 2019 13:08:23 -0600
- In-reply-to: <email@example.com>
- References: <20190108230616.GA17844@aldeberon-localdomain> <1546991099.782616.1629322016.75BE6566@webmail.messagingengine.com> <20190109164950.GD9285@bladeshadow.org> <firstname.lastname@example.org>
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.