[CentOS] [OT][Practices] The Case for RBAC/MAC -- WAS: SELinux threads, cynicism, one-upmanship, etc.

[Bryan J. Smith]

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)