Chris Mauritz <chrism@xxxxxxxxx> 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@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
