SELinux threads, cynicism, one-upmanship, etc.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



"Brian T. Brunner" <brian.t.brunner@xxxxxxxxxxxxxxx> wrote:
> What I implied, that Brian deleted,

Brian, I would invite you to go back and look at who you were
"debating" (if you can call it that).  Other than my original
analogy versus the firewall (after you brought up the concept
of a firewall), others have been "debating" you.

You owe me _no_ explaination.  I just don't agree with your
assertion that SELinux is "broken."  I've tried to point out
that under your same definition, a deny all outgoing policy
default on a firewall would also be considered "broken."

That's all.

> is that my product is in alien hands (some of whom can
spell
> "Linux") and must pass the muster of the testers who answer
to
> the marketeers who answer to the stock holders and
customers.

People who use Windows have problems when Windows 2000 Server
with Service Pack 3 is configured to CC EAL-3 standard as
well.  It's all about what security level is usable.  SELinux
is only going to raise the CC EAL certification of Linux,
which some customers _do_ consider as important.

And it's _always_ going to break things as a result.  Just as
RBAC/MAC does in Windows when it's enabled -- only far worse
(because nearly all Windows programs are RBAC/MAC ignorant).

> My product must fit the hands that work it. NONE of them
know
> what SELinux is (compared to Linux) and (properly) resent 
> every extent of my making them learn Linux.

Then that's a problem outside the scope of this discussion.

> Their day job has NOTHING to do with learning Linux, let
> alone SELinux.  Therefore, if SELinux breaks *anything* it
> gets switched off and is not part of the product.

And I'm _not_ the one that says you can't switch it off.  I
had a problem with you saying it is A) "broken" and B)
"firewalls" just work.  Once you started ""debating others, I
kinda just left it for awhile.

> If it is a seamless fit, with no regression, then it can be
> allowed.  Any self-important pedant who insists that this
> bully-boss attribute shall be catered to will be pedanted
off
> the drilling platform.  

This "bully boss attribute" is a "necessarily evil" in the
future of Linux.  RBAC/MAC isn't going away.  And it's not
broken.

> Walk home, twit!  Land is only 2 miles away (straight
down).

???

> "Ahhh but this is better and it is the future!"  When (if)
> it doesn't break my stride, it will become the present.

RBAC/MAC will _always_ cause headaches.
Just as a deny all outgoing policy default on a firewall
does.

> Until then it's already history.

RBAC/MAC enforcement isn't history.  It's the future.  Get
used to it because you're going to be seeing a lot more of
it.

If you don't want to deal with it now, fine.  I never said
you had to.  I just said that it's not "broken" -- it's a
kernel enforcement that you will run more and more into in
the future.

> This rant/diatribe is for the benefit of people making 
> "improvements" in a running, deployed, supported 
> product.

"Improvements" are subjective.  But most agree that RBAC/MAC
is one of the most important "improvements" in the future of
Linux.  And there is a very good chance it will become
defacto standard in Linux, because applications can be made
to work with it.

Unlike 99.9% of Windows software with NT's RBAC/MAC (at least
through version NT 5.1).

> I think, at this point, I'll depart from the debate.

It's a debate you're having with others than myself.  But you
can continue to respond to my posts as if I made the
statements if you wish.



-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux