On Sun, 2006-04-02 at 06:55 -0700, Benjamin Franz wrote: > On Sat, 1 Apr 2006, Craig White wrote: > > > > SELinux stuff isn't hard. But it does take a few minutes of time and > > attention to deal with the 'blocks' that arise - but it is these > > 'blocks' that confirm why it's installed in the first place. > > > > Granted it's easier to shut it off and I'm sure that when you are > > groping for justification for shutting off a layer of security on your > > Linux box, your above makes sense. The layer of security is for your > > benefit. Heck - why not shut off iptables? ' > > /sbin/service iptables stop' > > > > that makes it easier to use too. The reason you don't turn off iptables > > is because common sense tells you that it's a mistake. The same common > > sense should apply to SELinux - regardless of whether Debian/SuSE/Ubuntu > > etc. includes it. > > I decline to have SELinux occasionally grab the steering wheel and try to > take my machine over a cliff so I can act as Redhat's Beta Tester for > their selinux-policies. It is, and will remain, turned disabled on my > production servers until I am comfortable that more learning curve > incidents by Redhat where an update causes previously working machines to > suddenly have problems are not going to happen. > > Redhat did significant damage to my trust level regarding their ability to > safely deploy things that significantly extend the security model of linux > with their handling of both auditd and SELinux. Too often lately, Redhat's > efforts on the security front have 'made my machine more unstable' rather > than 'made it more secure'. > > In a year or two, when show stopping bugs in SELinux policies that were > being updated _literally_ every other week are only distant memories, I'll > consider turning it on in any higher mode than 'permissive'. > > Until then, the conservative position, the one focused on minimizing the > threats to my system's stable operation from _whatever_ source (INCLUDING > system updates from Redhat) says 'SELinux stays disabled'. > > -- > Benjamin Franz > > "Once burned, twice shy." ----- Fedora is a testing ground for leading edge technology and there is no more logical place to implement SELinux than in the leading edge. When you state that it is turned off on 'production servers', I wonder if we are actually now talking about Fedora, RHEL or one of the 're-spins' of RHEL because Fedora doesn't necessarily strike me as a 'stable' platform for a production server. Since this message base is about Fedora, I'll not wander into the topic of SELinux on RHEL 4 (or 're-spins') since that would be off topic. More to the issue however, Linux is both a production and a participatory system where it is expected that a 'user' minimally participate in providing feedback so the product is improved and your suggestions above suggest that your decision to turn it off is formed by an arrogance that has others participating while you opt out. More to the issue...if it's a production server, are you not stating that you are depriving your production system of the safeguards of the kernel level security because you can't be bothered with the security details. That would be a rather pathetic statement to make. If you are using FC-4 as a production server, the issues of SELinux have all been solved, the tools are mature and it is safe and practical. If you are using FC-5 as a production server, you are in less charted waters and probably should have your head examined since there are other issues with FC-5 than SELinux at this point. As for SELinux making a system 'unstable' - I can't envision a scenario that SELinux would do that. It might make a system unusable for the intended purposed but that is because the system administrator has neither the knowledge nor the toolsets to manage it. As I suggested above, both the knowledge base and toolsets are well defined for FC-4 so it is only a personal issue. Craig
