Chris Mauritz <chrism at 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! -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers)