"Brian T. Brunner" <brian.t.brunner@xxxxxxxxxxxxxxx> wrote:
> 1: SELinux is hereby invited to grow by giving pain to
> others, not to me. When it's ready for release to the
> unsuspecting world, let it be released in a 'default on'
> state then. Not now.
But how do you define "ready"???
Do we wait until all software is SELinux-aware?
Do we wait until all sysadmins know how to use it?
Same problems with ...
NPTL
ANSI C++
GLibC 2
and many others.
Red Hat is forcing people to adopt it, so people have to
comply. Because if they don't, they won't. And then it will
_never_ be "ready."
> SELinux is *broken* if it renders otherwise working
> applications dysfunctional as shipped.
Depends on your viewpoint.
The same was said about NPTL, ANSI C++ and GLibC 2.
Yet Red Hat regression tests _all_ its distros as a whole
before shipment. It verifies things work as they should.
That was true of the first Red Hat distro with NPTL, the
first distro with ANSI C++ compliant compilers and code, with
GLibC 2.
But then people configure things, use them in ways that
aren't stock, and things start to break. And the biggest
culprit is legacy software that isn't compatible or
compliant. Who's at fault then?
In the end, it's not about "fault" and it's not about
"broken." By the same definition, _real_ firewalls that do
outgoing as well as incoming blocking are "broken" as well.
Furthermore, the same could be said for higher-layer IDS/IPS
systems.
Red Hat always forces the issue. They get chastized for it.
Their software and/or defaults get declared as broken,
etc..., etc..., etc... In fact, I distinctly remember a
major complaint about Red Hat taking off suid on cdrecord,
which forced people to use proper permissions on the devices.
That was also, so-called, "broken." But then, Red Hat had
only one of the very few distros without the kernel 2.8.1.x
priority issue (because cdrecord didn't run suid). So who
was "broken" there?
It's all a matter of viewpoint.
> I don't mind being asked to volunteer to alpha/beta test
> software. What's done is to *compel* me to be a SELinux
> tester, or to disable it. Everybody who is inclined to
> help SELinux get ready for The Big Time Release, *please*
> accept my encouragement to do so.
SELinux is already "The Big Time" -- but the majority of
software on Linux is not. At some point, _someone_ has to
get people to care.
SELinux works. It's just that most software isn't designed
with it in mind. ;->
> Us other miserable grunts who want to beta test something
> else are best off disabling SELinux as of it's current
> behavior.
> "It's needed for security" meets the "necessary" test, but
> not the "proper" test, which won't be met until it works
> without breaking things.
Then you're going to be waiting _forever_.
Just like most people don't do "deny all outgoing" firewalls
either. They don't want have to deal with things.
I hate these meta-discussions. But I guess I'm tired of
seeing "compatibility issues" mistaken for "broken." SELinux
throws a wrench into a lot of programs that should be written
differently, and no amount of "SELinux hacking" is going to
be a "workaround" for some programs/configurations.
The mindset has to change. Otherwise, you will _never_ get
something like SELinux to work. And Linux won't be able to
reach higher CC levels.
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
