Somebody in the thread at some point said: > Andy Green wrote: > > [snip] > >> It's obviously up to you how you deal with that, but I strongly believe >> that you can't inherently trust machines on any internal network any > > My issues with SELinux are: > > (1) it is wrong-headed > (2) it is pervasive > (3) it has defects, and always will > > The additional "security" it offers to an already compromised > system is debatable. This thread proves it. That it causes I value it for what it can do at the moment of the attempted compromise. My external servers are set up to send me regular and very frequent emails with several log entries since the last email -- and I read all of those emails with care. If an attacker is stymied for even a little while because he didn't get a shell out of httpd, I will see what nearly happened and have the chance to step in. I think the decision to include selinux is right... people will use it and gain some increment of security from it if it doesn't make overt trouble. If you're sure the bad feelings that have stacked up against selinux are really deserved, you can always recook the appropriate packages having done stuff along the lines of sed s/--enable-selinux//g to the spec file, or in extremis move to your own distro. But I think it won't gain much of a following to define the distro by removing a feature rather than adding stuff. In fact I wrote up a giant procedure here http://warmcat.com/_wp/?p=35#more-35 for converting 1&1 dedicated servers that are on some weird FC4 - Debian mutant hybrid without selinux to F7 with selinux, involving reformatting their pervacious XFS partitions to ext3 entirely remotely. > I don't download and execute other people's programs. The whole distro is full of other peoples' programs though. > I don't permit Java or Javascript to run on my machine. > > I don't permit my mailer to use links or to download images. I must be pretty lax, Javascript is okay in a browser (not Thunderbird though) and I will click on email links after hovering to see where they go. >> You have to mix in the level of grief to implement it. For example >> everyone keeps agreeing that the initscripts and especially shutdown can >> be made MUCH better, but it's so frightening to take care of everything >> with minimal breakage that somehow Fedora doesn't seem to get anywhere >> with it (over years). > > I don't know to what you refer. There are a few projects around that replace the venerable "System V" -- it refers to some ancient Unix flavour AIUI -- initscripts. This is the stuff defined in /etc/init.d and /etc/rcx.d that happens after the kernel boots, it goes through bringing up services like web servers, sshd and so on and says, hopefully, [OK] a lot. It's the stuff that chkconfig actually turns on and off. In other distros they have moved to newer initscript systems that run non-dependent scripts in parallel and see a pretty good reduction in boot time accordingly. They threw out most of the shutdown action to it is ~instantaneous. It keeps getting discussed on fedora-devel, I'm not sure there are any voices against the general plan, but it doesn't cross the threshold into the painful action. I mentioned it because there was a proposition that good ideas will get adopted and you can tell a bad idea because other people aren't doing it already. Improved initscripts is pretty much universally approved of but doesn't get adopted in Fedora so far. -Andy
