Peter Farrow <peter at farrows.org> wrote: > Thats because its entirely possible to make a system secure > without Selinux, it was only born in Centos from Version 4. There is _no_ possible way to make a system secure _except_ for yanking the plug. Furthermore, anytime you offer networking services, you open up holes in the system. > While I would never recommend turning off a firewall, This is far too broad of a statement. First off, "firewalls" can actually not only be a _false_ sense of security, but they are quite _indifferent_ at times. Most people assume firewalls must be turned on because many platforms have so many services that _always_ run, _regardless_ of configuration. That is a leftover from the Windows world. A UNIX/Linux system with select networking services that are known to be running and accepting all packets from any source IP benefit virtually _little_ from source address packet inspection (let alone TCP Wrappers becomes useless). At that point, you're talking more about intrusion detection than anything. And that's typically at layer 5+. The new focus is on IDS/IPS at layer 7 in today's world of unifying HTTP services. The overwhelming majority of firewalls only address layer-3/4 security, layer-2 if you're lucky, but virtually _never_ layer 5+. > I would recommend turning off Selinux: I would recommend _against_ that. That's _exactly_ saying that you don't need different user logins if you have groups defined, because you've entrusted people in a group of the same access. You're ignoring many, many things accountability-wise. > a firewall doesn't stop stuff on the box working properly Of course not because it only deals with (largely) blocking layer-3/4 communcation. It does absolutely nothing to deal with layer-5+ exploits -- let alone local issues. > as it ships, Selinux does. Of course! Anytime you implement RBAC/MAC, you're going to break things. But the answer is _not_ to merely turn it off, it's to write the software to work with RBAC/MAC. Like it or not, Linux software is going to have to "grow up" and face the RBAC/MAC music. In addition to software, that requires administrators learning to deal with it. To do less is to leave Linux _well_behind_ other OSes in the Common Criteria certifications -- certifications that _do_ exist for damn good reasons. > For example anything that would stop squid running properly > out of the box (as Selinux does) is of limited value, Value to whom? The person who is trying to secure the server? Or someone who just wants Squid to work? REALITY: SELinux is no different than any other security mechanism, or any other troubleshooting. If something doesn't work, you turn off all sorts of constraints. If it starts working suddenly because you turned something off, that doesn't necessarily mean whatever you turned off is the "problem," but that its current configuration prevents something from working. You can either choose to find out why, or you can turn it off. But make no mistake, SELinux is _not_ just "going away" because people don't want to deal with it. Just like NPTL, just like ANSI C++ compliance before that and just like GLibC 2 before that. I have continually agreed with Red Hat's insistence on certain technologies because without them, Linux is seriously _not_ moving forward. Heck, look at Windows! 99.9% of Windows applications won't run with the full NT security model enabled. In the Linux world, you start enforcing the full security of the OS, and the applications fall in-line. SELinux is just another set of hurdles to overcome in Linux -- things that _other_ UNIX flavors _have_. Linux needs to join them or people like myself _will_ be running Solaris on our next server purchase (there is already the filesystem argument I've blabbed about prior, with RBAC/MAC being an increasing consideration. ;-) > in this instance its not required, "Not required" in what context? That's the problem. > it gets in the way, it IS easily possible to have > a secure system without Selinux, whereas that is doubtful > without a firewall. I _disagree_ entirely, and that is an overly broad statement. One might argue that a layer-3/4 packet inspector is rather "false security" when it comes to a layer-7 proxy service. ;-> Now SELinux is not a layer-7 packet inspector. But it _does_ prevent applications from accessing parts of the system that should not be allowed to access. It's not perfect and God knows Red Hat begs for new rules everyday to deal with things, but the headaches don't stop _until_ people start getting serious about putting SELinux in the fore-front of their considerations. > Chalk and cheese springs to mind. > If Selinux is the "baby" in your metaphor, then the best > thing to with it is hold it under the water until it stops > moving.... No offense, but Solaris continues to gain back Linux mindshare for this, and other reasons. No, it's not GPL-like, but it's MPL-like. If SELinux isn't adopted, Red Hat _knows_ it's going to be a serious mark against Solaris. > For those of us who know how to configure secure systems > (and I'm not suggesting you don't Tony by any stretch) > Selinux is additionaly bloat I (we) don't really need. Fine for you'all. But I do want and need SELinux. Yes, I disable it on some systems. But at other times, I've caught a few things that should not access things. > It just slows the system down... > I''ve never needed it...... But lack of SELinux adoption will slow Linux down. Red Hat knows this. -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers)