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