Chris Mauritz chrism@imntv.com wrote:
SELinux shouldn't be turned on by default and in many cases simply creates extra overhead/bloat on a system that
doesn't
really need it.
Okay, I give. I would like people to quantity/quality "doesn't really need it." I've really "bit my lip" on this since just after the early stuff, but it keeps coming up over and over.
Frankly, I have to join in the viewpoint of others who run some serious IT operations. People who don't see the value in RBAC/MAC are just ... and I'm sorry I have to say it this way ... "naive"?
It's more than just CC EAL certification. It's about defense-in-depth.
Building a firewall?
But how many filters these day are no longer just doing layer-2 frame, layer-3 IP or NAT and layer-4 service/PAT? They are now doing proxying at the layer-5/6/7 session, presentation and application filtering? Those are intelligent filters, a running service, and they need to be contained at the kernel.
Building a hardened box that's going to be exposed to the
net
at a datacenter?
RBAC/MAC is not just for Internet exposed systems. If you honestly aren't applying a set of defense-in-depth of several layers in a SMB or later, then you're really ignoring a lot. RBAC/MAC is just as important for internally exposed systems -- private networks between companies, VPN clients from off-site who might be compromised, etc... It's about keeping out the unexpected.
Having some kernel-level RBAC/MAC saved me about 40 hours of work when someone put the wrong data on the wrong network. I could show, _in_detail_, how far that data reached into my network, and where the data did not go. Now that's just auditing.
Let's talk about a compromise of a partner company -- one that had certain privilege access to some of my systems. 2 sets of internal firewalls, totally bypassed because the access by that system was legit to the layer-2-4 packet inspection! They got into my system with that privileged access, but thanx to RBAC, they couldn't run but a few binaries and access a few files!
[ NOTE: The system wasn't Linux. ;-]
Great, then it might be worth your while to wrestle with it and take the time to figure out why it's breaking your applications.
That's what I have to do everytime I put in a layer-2-4 packet inspector that denies _all_ traffic by default, or when I put in HTML/XML layer-7 gateways for richer services. Now I'm just doing it at the application server itself -- guaranteeing that some services can't be used to access areas of the box, possible the rest of the subnet (c/o that box), thanx to RBAC/MAC.
All the really good SAs I've ever had, tended to be
somewhat
frugal with their time and tended not to waste it on things
they didn't absolutely need or that didn't somehow make their lives easier.
Making their lives easier is the problem. Far too often people get something to work and leave it. Or they blindly believe something is secure -- especially a layer-7 service by a layer-2-4 stateful packet inspector.
The effort put forth in an environment that calls for RBAC/MAC is well worth the reduced headaches. Net-facing or non-net-facing. Heck, having a physical connection to anything is the root problem -- no matter how many filters things go through, there is always a way! And I've seen it too!