[OT][Practices] The Case for RBAC/MAC -- Seat Belts Kill ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Sat, 2005-11-19 at 10:41 -0600, Les Mikesell wrote:
> Yes, but when the box gets cracked _because_ they are using the
> latest new thing their distribution added under the guise of
> increased security, as happened with ssh a while back,
> ... cut ...

For the last time, let's _stop_ comparing SELinux to services!
And that includes services that "escalate privilege" like suexec.
SELinux does _not_ grant new privilege, it _only_ removes them.

Compare SELinux to NetFilter.

NetFilter removes access from the IP stack.
SELinux removes access from normal kernel authorization.

Yes, you can write an incorrect IPTables rule and grant more access than
a correctly written one.  But you can_not_ write an IPTables rule that
grants more access than if NetFilter is disabled!

Under the same token, you can write incorrect SELinux rules that grant
more access than a correctly written one.  But you can_not_ write an
SELinux rule that grants more access than if SELinux is disabled!

The only possible case where SELinux/NetFilter might be a buffer
overflow in the code.  That has _nothing_ to do with rule writing, but
the existence in the kernel itself!  That's it!  Otherwise, there is
virtually _no_ way any SELinux/NetFilter functionality can compromise a
system versus being disabled!

If you don't understand these _facts_ by now, then you really don't
understand how SELinux or NetFilter work compared to traditional
security mechanisms in user-space.  They _never_ grant new privileges,
only _remove_ them -- and not as a service, but at the kernel's core.

SELinux/NetFilter in the kernel are like seat belts in a car.

They are a major pest in your normal, daily activities, and they will
_never_ get better.  At the most we can devise newer and less intrusive
ways to restrain you over time, but they will _always_ be a "bug."

There is virtually no way they can introduce more liability to your
overall safety, unless you really nitpick on minor things.  E.g., there
is a chance you _could_ die if you drive into a retention pond and in
the 1-3 seconds it takes you remove your seat belt, those were the 1-3
seconds you needed to reach the surface before you became unconscious.

To make that argument with regards to retention ponds about seat belts
is to make the same argument that you won't enable SELinux/NetFilter
(e.g., IPTables) default rules because they could have a buffer overflow
somewhere.  If you're worried about buffer overflows, then build a
kernel without SELinux, NetFilter and anything else that could
potentially have buffer overflows!

Instead of continuing that rather pathetic viewpoint (and I'm sorry,
that's what it is), just admit you don't want to be constrained by seat
belts.


-- 
Bryan J. Smith   b.j.smith@xxxxxxxx   http://thebs413.blogspot.com
-------------------------------------------------------------------
For everything else *COUGH*commercials*COUGH* there's "ManningCard"

-- 
Bryan J. Smith   b.j.smith@xxxxxxxx   http://thebs413.blogspot.com
-------------------------------------------------------------------
For everything else *COUGH*commercials*COUGH* there's "ManningCard"



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux