Corrected version ...
"Bryan J. Smith" thebs413@earthlink.net wrote:
There is a _world_ of difference between bugs in a service, and bugs in a kernel supervisory RBAC/MAC that prevents a service from doing what it shouldn't. Let's go back to my analogy to firewalls ... Which is more dangerous? A) Allows all outgoing access by default, then deny certain access? B) Deny all outgoing access by default, then write writes to allow certain acces?
B) Deny all outgoing access by default, the write rights (rules) to allow certain access?
In the majority of cases, a firewall doing "B" will prevent someone from doing something you didn't expect than "A". RBAC/MAC isn't about addressing how you think someone might circumvent a service from what it's normally supposed to be allowed to do. That's traditional "hardening" like "B" in a firewall. ;->
Er, that's traditional "hardening" like "A" in a firewall.
[ You try to figure out how something can be circumvented and used and attempt deny to deny. ]
RBAC/MAC is about only allowing what you think someone should be able to do from a service and
_denying_everything_
else. That's like "B". "B" is a major PITA because you find something that you have to allow through, then test again and find yet
another,
yet another, then yet another ... and you get tired of it. Same deal with RBAC/MAC, you prevent everything by default, then enable something, then another thing, then another
thing
and ... damn it ... it still won't work!
With "A" ... yeah, it works much quicker! But it requires you to think of _anything_ a service might try to do. Well, if that was the case, why don't we just fix the bugs
in
the service instead of doing "A"?
Exactly! We do "B" because we don't know all the bugs or what could happen! Defense-in-depth -- we try to write bug-free code, but then we use RBAC/MAC to enforce things in case we missed something. ... Ummm, no. RBAC/MAC _prevents_additional_ access over traditional UNIX DAC security. It supplements it, it does _not_ remove legacy DAC security. That's a misnomer. ;->
It's just like a deny-all outgoing default policy on a firewall.
We know that a compromised system might have Sub7 and countless other rootkits installed. So we block those outgoing, destination ports they commonly use.
But what about the rootkits we don't know about? Blocking _all_ ports by default would catch those!