How do we define Ready? I gave that answer in the text you replied to: when it doesn't break things. You ask about applications not being SELinux aware. The proper things for SELinux to do in those cases is advise the operator that SELinux can't manage this app because it isn't SELinux aware, and that whatever security holes that application embodies are outside the scope of SELinux.
This is consistent with SELinux being a *service* to the operator, not a bully-boss to the operator and the authors/maintainers of every package Joe Operator might have on his system.
SELinux is *broken* if it renders otherwise working applications dysfunctional as shipped.
Depends on your viewpoint.
No, it doesn't. It's about ownership of control. Is this RedHats' system to break if they want to compel me to do things their way? If not, then distributing SELinux with a default of 'on' when it breaks running systems is distributing a broken software package.
SELinux works. It's just that most software isn't designed with it in mind. ;->
Translate: Everybody is out of step except my boy! (and those who happen to be in step with him).
I say Broken, and Disabled for Good.
The proper things for SELinux to do in cases of non-compliant apps is to advise the operator that SELinux can't manage this app because it isn't SELinux aware, and that whatever security holes that application embodies are outside the scope of SELinux. That's a *service*. Breaking said applications is a broken application.
Brian Brunner brian.t.brunner@gai-tronics.com (610)796-5838
thebs413@earthlink.net 11/14/05 10:49AM >>>
"Brian T. Brunner" brian.t.brunner@gai-tronics.com 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.
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.
"Brian T. Brunner" brian.t.brunner@gai-tronics.com wrote:
How do we define Ready? I gave that answer in the text you replied to: when it doesn't break things.
How's forever work for you? ;->
NPTL, ANSI C++, GLibC 2 and many other adoptions Red Hat has made still break things. Heck, we're not even looking at recent things -- from 4K stacks to ACLs. ;->
You ask about applications not being SELinux aware. The proper things for SELinux to do in those cases is advise the operator that SELinux can't manage this app because it isn't SELinux aware, and that whatever security holes that application embodies are outside the scope of SELinux.
I think that's what the advisement is. You can start disabling some aspects of SELinux -- such as with permissive mode.
This is consistent with SELinux being a *service* to the operator, not a bully-boss to the operator and the authors/maintainers of every package Joe Operator might have on his system.
Actually, SELinux _is_ a "bully-boss" to the operator. It will _always_ be a "bully-boss" to the operator.
No, it doesn't.
I think _many_ people other than myself have seen _many_ viewpoints on this issue. Why many people seem to think that there must be no less than an absolutism on SELinux until it accomplishes no less than the _impossible_ is beyond me.
It's about ownership of control. Is this RedHats' system to break if they want to compel me to do things their way?
Yes. And you have these options.. 1. Learn it and see if it fits 2. Put it into another mode (e.g., permissive) 3. Disable it 4. Look to another distro choice
Red Hat has its reasons, and it's not going to change those reasons. Common Criteria is a major driver right now because of Linux can achive higher CC levels than Windows, while still running applications (which Windows virtually can_not_ do), then Microsoft will lose federal installations en masse.
If not, then distributing SELinux with a default of 'on' when it breaks running systems is distributing a broken software package.
SELinux will _always_ break running systems. Just like a "deny all outgoing" firewall will too.
Translate: Everybody is out of step except my boy! (and those who happen to be in step with him).
Exactly! SELinux by default is here to stay if you choose Red Hat.
I say Broken, and Disabled for Good.
Then that's your choice. Red Hat has made their default, but you still have choice.
The proper things for SELinux to do in cases of non-compliant apps is to advise the operator that SELinux can't manage this app because it isn't SELinux aware, and that whatever security holes that application embodies are outside the scope of SELinux. That's a *service*.
You seem to fail to understand what SELinux does. ;->
Breaking said applications is a broken application.
Then add outgoing firewalls to the same list. Oh, you just turn an outgoing firewall off? Well then, that's your solution. ;->
I don't know if I could make a better analogy.
-- Bryan
P.S. SELinux is _not_ a service. It is an _enforcement_ in the kernel. There are hundreds of rules. Applications either learn to make SELinux considerations, help write rules, or a combination of both. SELinux is basically the biggest change to Linux in a long, long time -- breaking the 30+ year legacy UNIX model.
-
Brian T. Brunner -
Bryan J. Smith