Corrected version ...
"Bryan J. Smith" <thebs413@xxxxxxxxxxxxx> 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@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
