Les Mikesell lesmikesell@gmail.com wrote:
Well, it may or may not be true. It is certainly well-intentioned, but we are talking about bugs and
unexpected
behavior here which by definition aren't predictable. You
may,
by adding extra layers of security, protect against some
flaw
that will turn up even in the simple, well understood
existing
programming.
That's the idea behind RBAC/MAC.
Or, you may, by adding extra layers of complexity and less-tested code, introduce new vulnerabilities that no one understands yet.
This is _far_ less likely. Why? RBAC/MAC doesn't "grant" access by default. It removes it! RBAC/MAC is _not_ a "service" -- it's a kernel subsystem that removes access.
It's like saying the Linux NetFilter (which is used by IPTables for those that don't know) introduces vunerabilities into the IP stack. NetFilter only _denies_ access, it does _not_ allow any "new" access! @-p
That's something that people keep missing here. RBAC/MAC is _not_ a "service" anymor ethan NetFilter is! Sure, you can screw up your RBAC/MAC rules just like IPTables rules, but not any more than having _no_ rules!
[ Please, please tell me some lightbulbs out there went off? ;-]
And even more likely, by making normal operations more difficult, you set up the authorized users to need more outside help and more chances for social engineering efforts to steal their credentials.
Ahhh, the chronic "not supportable" issue. Yes, well in my biased experience, if you need such controls, they are not optional. But I've lost those arguments before ...
On bank networks no less!