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