Les Mikesell <lesmikesell@xxxxxxxxx> 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@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
