Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
> Not exactly. In my case I just realize that there are 30
> years of history behind expecting all unix access control
> to be in the filesystem in the owner, group and modes of
> the files.
But is it? You have root, so such access is _bypassed_!
Superuser is incompatible with a complete RBAC/MAC. ;->
> We are talking about bugs here. Why are you so convinced
> that the new code you just introduced to enforce this new
> policy does not in fact introduce new bugs?
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?
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. ;->
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.
> Remember that old code that you are trying to protect has
many,
> many years of finding and fixing exploits. They may in
fact
> all be fixed now and you are just setting up new ones that
we
> don't know about yet with this change regardless of how
> well-intentioned it is.
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. ;->
> Have you watched the changelogs to see if in fact any
> problems have been found and fixed so far?
Yes. New rulesets come out regularly on Rawhide.
> Speaking of backups, have you tested the method you use to
> make sure it restores the attributes SELinux needs to work?
That why I _hate_ Ext3. Only Star does this, and I don't
trust it. e2dump is a joke.
With XFS, there is no issue. It's in the inode and gets
backed up with xfsdump.
I agree with you 100%, if Red Hat is _serious_ about SELinux,
they really need to address the filesystem/backup issue.
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
