Oh, my. Greed, like entropy, doesn't have to be "ingrained". It's a direct and predictable result of the benefits, to individuals in a complex environment, of being greedy, much as entropy is a predictable result of complex systems allowed to have random interactions. And it doesn't take _intelligence_ to limit. Wolves, bees, even bacteria have ways to limit excess growth. These ways may be nasty: killing and eating those who hoard and wind up with most of the food, for example, is a nasty business.
Now, can intelligence often do a better job of limiting the destructive and maximizing resources for the species? Sure. That's why we have civilizations and cultures, to preserve and spread information to the next generation. But don't ignore those "primitive" impulses. It's like ignoring physics when you try to design a computer: it keeps popping up, and you can't just ignore it.
Oh, please. The idea of a utopian ideal where "we've outgrown greed" is so funny in both evolutionary terms and biological terms it's... well, it's like thinking that randomness ill cause your hostess's underwear to jump several feet to the left for quantum uncertainty reasons. It can be amusing to discuss, but it isn't going to happen for "evolutionary" reasons. You'll just have to get her underwear moved the normal way, alcohol and fast talking.
As opposed to the small companies, where they haven't bothered to do any security yet? I'm explaining to a corporate partner right now why using the built-in version of subversion on RHEL with an HTTP setup, and NFS home directories, and using the Kerberos of Active Directory for Subversion passwords, is an exquisitely bad idea. (Your passwords are silently stored in clear text, and available over NFS shares.) The people who knew, and cared, had been told it wasn't on their tasklist. The managers further up assumed that it was safe because it was HTTPS. The mangers in the *middle* hadn't been willing to discomfit people by teaching them to use SSH with keys, or spend the time having to type in passwords.
So almost *every user's primary keys* were available to anyone who plugged in a live CD and poked around for NFS mountable home directories and bothered to mount them and look at/home/$USR/.subversn/auth/. This is a long-existing, publicly announced problem. Every environment where I've seen this sort of thing occur has been small: The big companies have a security architect whose job it is to scream about this kind of thing, and to insist that it be addressed. And the big companies are willing to have one person run the daily script to look for these passwords stored in people's home directories. (It only takes one person running an out-of-date OS accessing NFS home directories, or who hasn't updated to subversion 1.6 which at least asks before it stores your passwords.) Or a policy of not having password free SSH keys, and one person to notice their NFS mounted SSH keys without passwords that present the same sort of problem.
What fun! Thank you for commenting: I'm not an expert.
But energy is deposited in the tissue by the MRI scan itself: if no energy were deposited, there'd be nothing to measure. That's basic physics, as described in Schroedinger's equations. The higher the resolutions of the scans, the more energy _must_ be deposited in the tissue. And while the MRI energy is safer in many ways than X-rays, you're still coupling to the water molecules: scans that not only provide cell width resolution of the 2-D scan, and which are taken at sufficiently thin slices in the third dimension to provide a full 3-D image at the cellular range, in a reasonable period of time.... That's going to deposit even more energy in the tissue. Are you really _sure_ that won't be enough to damage tissue as sensitive as brain tissue?
And I'm sorry to say, cellular resolution is _not_ sufficient to do a 1:1 brain model. It would be like a circuit layout that showed the chips, but didn't show any of the wiring between them. You can make some assumptions based on what is near what, but the devil is in the details. You need the map of the connections to try and create a duplicate, you can't just randomly add cross-wirings and expect it to work. You might try to evolve such a system: that's what nature does, with our brains evolving from out physiology and our environment, but you don't get duplicates that way and you certainly don't get 1:1 mapping.
Sadly, it is. Many schools, even in third world and fourth world nations, teach English as their second language for people to participate in business with other groups, even other cultures within their same nations. English _is_ the trade language for this era. And compared to the absolute nonsensical debris most speech algorithms generate in poor acoustic environments, human brains designed by evolution and by education to tease speech out of background environments remain the best speech recognition tool.
Why don't they just use these (http://www.sandstorm.net/products/phonesweep/). Amusingly enough, the company sells arms to both sides of the telemarketing conflict, with (http://www.sandstorm.net/products/sandtrap/).
Neither can some humans. Look up 'congenital insensitivity to pain' to see about some people who _cannot_ feel physical pain, but who are, in fact, intelligent people.
Not hard, although it may take longer. Do some jumping jacks: then stop.
Secondary control over your autonomous system counts as 'control', the same way that pushing a gas pedal counts as 'control' of a car. You don't actually need to have your hand on the carburetor to change fuel and airflow, just the more general controls.
I know enough to say: he's mistaken. The tools to image biological structures with sufficient resolution for a '1:1' image would damage them profoundly, even in the setup to make the images. Non-invasive techniques like CT scans and MRI deposit significant energy, the higher the resolution, the more energy, and certainly cannot map to the individual cell or neural junction level. An electron microscope might be able to, but you have freeze it and slice it first.
One may as well say that we can read CD's with a good enough phonograph player, or program your PC with an X-ray machine. You can discover a lot about the layout and overall layout, but many of the properties are also emergent: they arise from having enough components bound together in specific structures that is neither obvious nor directly derivable from the knowledge of the lowest layer components.
They'll try. Like lots of companies making web search engines, Iphone-killers, and other exciting tools, most of them are likely to suck even worse than the current provider: they're vulnerable to the same market forces and the same sorts of middle management, short-sighted fools who helped create GoDaddy at the expense of the rest of the world.
Velcro these days is _necessary_. I've seen far too many "skilled technicians" slice open cables when cutting open Ty-Wraps that have been bundled too tightly, and had fiber-optic fail because similar idiots bent it too firmly Ty-Wrapping it down.
Cable labels are very helpful: 3com makes label dispensers that help, and when you have 3 or 4 network cables on different subnets but all the same color, they're very helpful indeed. They also help sort out old PS/2 cables for mouse or keyboard, number KVM cables, etc.
Power supplies are a problem. Far too many companies use power bricks that plug directly into the socket, and block everything else. For such foolish designes, one-foot power extenders are very useful. Short extenders also useful for USB devices that are supposed to fit directly into the slot, but block other defices. (Wireless USB devices are particularly bad about this.)
Other issues include _not_ stringing power strip onto power strip to provide enough outlets: get strips with longer cables, probably of heavier gauge, and be sure to tie them directly to the wall socket to avoid adventures.
Yes. Steam engines with modern materials are surprisingly lightweight, efficient, and effective, without the complexities of the internal combustion engine.
You've got me on the "head crash" point somewhat. You'd think that a CD laser couldn't head crash, but you've got spinning objects inside boxes with a head that has to move radially, and a lot of them are made amazingly poorly. Mechanical absurdities happen, and the insertion and removal of CD's and their physically open nature tends to allow a lot of debris to accumulate. The result is dust and hair and grit causing mechanical damage: I'm not saying this is a large source of the common damage, but I've certainly seen it in household machines and laptops and poorly maintained server environments. (Company servers shoved in poorly maintained closets, for example.)
And yes, CAV is helpful in many ways: but the random access introduces some fascinating lateral stresses on the mounted reader and potentially writer components, and those darn things _fail_ and do serious physical abuses to discs in the process.
The virtual LAN channel, provided by tools like load balancers, is fine for protecting you from _outside_ access to your internal data channels. But it doesn't do _anything_ to protect you from internal access! This is the hard, crunchy shell, soft chewy underbelly approach, and it remains unfortunately popular. It only takes _one_ malicious internal node. Once a cracker has gotten inside, whether it's an infected laptop connected by VPN, a Windows zombie infected by who-knows-what channel, a VPN connected laptop that you personally use for remote debugging and which happens to have become rootkitted by any means, or a switch that someone else's machine in the datacenter has been able to access due to poor password choice or an unpatched vulnerability, you are _screwed_ once someone else is inside.
The potential vulnerabilities, many of which I've seen personally, are legion. It's why I consider a remote data center, or any environment where I don't personally know and own every single node, to be more like a hotel room: you don't leave the money or jewelry sitting out where someone might be tempted, and you don't leave unencrypted passwords in use _anywhere_.
Good luck with that "understanding". There are plenty of "emergent" properties of complex systems, not predictable from the simpler rules used to create the physical basis of it, but which emerge as the system grows in size, duration, or complexity.
Interesting material on the new Fcgid, thank you for the pointer.
That 'telnet server has only one entry point' is somewhere that you and I disagree. Take a look at a nasty little technique called 'arp poisoning', that can let other devices on your network confuse your switches and get copies of your packets. It's nasty, and a clear proof that running clear text password handling inside a network without _absolute_ control of every node's security leaves you vulnerable to a single compromised server stealing packets from throughout your local network.
There are ways to block it, but I haven't seen anyone in the last 8 years actually bother, in multiple large and small environments.
_Yes_, I understand the technology. No, a rapper does not have to "press" it in a linear fashion: half the fun for a skilled disc jockey at a rap session is tweaking the effects, and that requires dynamic control, not a "pressed" recording. It's the difference between a live concert and a live concert tape.
Moreover, while ideally there is no physical contact, in real live, heads crash. Disks flex, and deform, as they're spun and stopped and spun and stopped. So please do not assume that the wear of a music recording (with several minutes of consecutively recorded music) are handled or physically wear the same as randomly accessed data. That kind of simplification is why people thought CD's and DVD's would last for decades, and why in normal use in real life they last far less.
Well, I personally appreciate that it warns me when people are doing stupid things like telling me, as the web admin and the security admin, that a.htaccess has been set to run CGI scripts out of a local directory, by having them fail outright and provide a log of why they failed. This lets him know that it was a bad idea, rather than proceeding merrily along and proceeding to _think_ about what he's doing, earlier in the process.
Yes, he probably 'abused' it by playing the game. Music CD's have relative simple behavior: they read a track at a time, in a linear fashion, and are unlikely to do hunt&peck data searches. Game CD's are begging to suffer the worst abuses of start-stop usages, for many continuous hours, in a way no music or video media will suffer unless used by a rapper stringing together 3-second segments in strange orders.
Oh, I _wish_ bleeding edge developers would keep such tools up-to-date. It's inherently unstable, though: developments in one package may conflict with those of other packages, in ways that can be nightmarish to resolve. Take a look at Perl's changes in what modules are part of the core Perl tarball, and what are add-ons, to see what such an upgrade can destabilize. So many developers upgrade only those individual components they need, when they need them.
I like to keep a system near the bleeding edge myself, so that I can run into the problem before the developers do and hand them a solution, preferably by sending the bug report upstream and getting it patched in the source itself. But it's a huge timesink.
xa wrote: > Wait... SELinux is easier to configure than Apache?!!
Oh, dear. SELinux often has working, well-defined structure that programmers are wise to follow (such as keeping CGI tools in the standard Apach location,/var/www/cgi-bin, rather than scattered around your filesystem).
And oh, my, yes, PHP utilities add their own flavor to Apache security. (They basically ignore it altogether: there is a lot of very, very dangerous PHP out there.) It basically has all the delightful power of Perl, but running as the shared 'httpd' or 'apache' user, and with less debugging, and with even less quality control than CPAN provides. It's actually quite frightening to see the utilities people stuff in PHP modules expected to run on semi-public webservers.
I'd be very curous to see guidelines or notes on getting PHP utilities running as their own user. There are some old utilities for managing some shared resources I'd love to see more properly isolated from the 'httpd' user access, and I'd particularly like to provide that for Subversion and git utilities. That's not necessarily PHP, but it's still a good idea to separate the 'httpd' user from the 'svn' user to allow better control of SSH access in parallel to HTTP access to a Subversion repository. I haven't seen any coherent guidelines for that, just huge numbers of webpages which break down to "and then a miracle occurs" in the actual setup.
But telnet use, like the older 'rsh' use on which ssh is based, allows wholesale password sniffing in a way that even flawed SSH servers do not. Guaranteeing that "your network isn't sniffed" is like guaranteeing that your date doesn't have venereal disease. It's just safer to stick with serious protection until you actually have a reason to use telnet, or to want children.
Not quite completely free: RedHat's "RHN" service, for example, takes a paid subscription and is incompatible with non-RedHat clients. Also, their work on "GFS" is not entirely open source, at least at my last review of it, primarily because its original authors had not open sourced it for various reasons.
But RedHat is very good indeed at returning their tools to the free software and open source worlds: they're a model of how to do so and actually add value.
SELinux does help prevent tools from executing in locations or in places that are inappropriate: it helps reduce the destructive capabilities of components that are mis-installed, installed without proper permissions, or that have certain classes of errors. It also helps force you to think before doing something foolish, such as running CGI tools that are not in/var/www/cgi-bin/: it's too easy for foolish people to use.htaccess or poorly handled HTTPD include directives to include some very foolish CGI tools, and I've had SELinux detect this and prevent a fool from running his very dangerous CGI utilities out of his NFS mounted home directory. So it has uses.
Now, that "Jack will never learn to lock it down, so let's not help him so that he has to do it all from scratch himself" message you seem to have is, I'm afraid to say, both popular and insane. Jack _does not want_ to have to learn this material. Jack just wants to have his web site work. Jack doesn't have the time or the money to invest in a long-term career in server security programming: This is a modest tool that can be helpful against some classic errors. (Running CGI utilities out of home directories is my favorite that is blocked by SELinux by default.)
They ruin otherwise working code that was written in slightly different environments, and for which the very arcane behavior of SELinux has not been tuned. They're also often difficult to write test suites for, especially the unpredictability of SELinux changes, since they affect behavior due to factors entirely outside the control of the particular program author: they affect behavior based on where the package installs the code and what SELinux policies are in place.
It's gotten better: Linux operating system authors have gotten more capable with it, and the software authors have learned not to stuff everything wherevery they feel like (with the exception of Dan Bernstein, but he's loosened his licenses, so we can fix that now).
Slashdot Mirror
Oh, my. Greed, like entropy, doesn't have to be "ingrained". It's a direct and predictable result of the benefits, to individuals in a complex environment, of being greedy, much as entropy is a predictable result of complex systems allowed to have random interactions. And it doesn't take _intelligence_ to limit. Wolves, bees, even bacteria have ways to limit excess growth. These ways may be nasty: killing and eating those who hoard and wind up with most of the food, for example, is a nasty business.
Now, can intelligence often do a better job of limiting the destructive and maximizing resources for the species? Sure. That's why we have civilizations and cultures, to preserve and spread information to the next generation. But don't ignore those "primitive" impulses. It's like ignoring physics when you try to design a computer: it keeps popping up, and you can't just ignore it.
Oh, please. The idea of a utopian ideal where "we've outgrown greed" is so funny in both evolutionary terms and biological terms it's... well, it's like thinking that randomness ill cause your hostess's underwear to jump several feet to the left for quantum uncertainty reasons. It can be amusing to discuss, but it isn't going to happen for "evolutionary" reasons. You'll just have to get her underwear moved the normal way, alcohol and fast talking.
Oh, dear. Pleae excuse that run-on paragraph: I occasionally forget to hit the 'Plain Old Text' option when I write.
As opposed to the small companies, where they haven't bothered to do any security yet? I'm explaining to a corporate partner right now why using the built-in version of subversion on RHEL with an HTTP setup, and NFS home directories, and using the Kerberos of Active Directory for Subversion passwords, is an exquisitely bad idea. (Your passwords are silently stored in clear text, and available over NFS shares.) The people who knew, and cared, had been told it wasn't on their tasklist. The managers further up assumed that it was safe because it was HTTPS. The mangers in the *middle* hadn't been willing to discomfit people by teaching them to use SSH with keys, or spend the time having to type in passwords. So almost *every user's primary keys* were available to anyone who plugged in a live CD and poked around for NFS mountable home directories and bothered to mount them and look at /home/$USR/.subversn/auth/. This is a long-existing, publicly announced problem. Every environment where I've seen this sort of thing occur has been small: The big companies have a security architect whose job it is to scream about this kind of thing, and to insist that it be addressed. And the big companies are willing to have one person run the daily script to look for these passwords stored in people's home directories. (It only takes one person running an out-of-date OS accessing NFS home directories, or who hasn't updated to subversion 1.6 which at least asks before it stores your passwords.) Or a policy of not having password free SSH keys, and one person to notice their NFS mounted SSH keys without passwords that present the same sort of problem.
What fun! Thank you for commenting: I'm not an expert.
But energy is deposited in the tissue by the MRI scan itself: if no energy were deposited, there'd be nothing to measure. That's basic physics, as described in Schroedinger's equations. The higher the resolutions of the scans, the more energy _must_ be deposited in the tissue. And while the MRI energy is safer in many ways than X-rays, you're still coupling to the water molecules: scans that not only provide cell width resolution of the 2-D scan, and which are taken at sufficiently thin slices in the third dimension to provide a full 3-D image at the cellular range, in a reasonable period of time.... That's going to deposit even more energy in the tissue. Are you really _sure_ that won't be enough to damage tissue as sensitive as brain tissue?
And I'm sorry to say, cellular resolution is _not_ sufficient to do a 1:1 brain model. It would be like a circuit layout that showed the chips, but didn't show any of the wiring between them. You can make some assumptions based on what is near what, but the devil is in the details. You need the map of the connections to try and create a duplicate, you can't just randomly add cross-wirings and expect it to work. You might try to evolve such a system: that's what nature does, with our brains evolving from out physiology and our environment, but you don't get duplicates that way and you certainly don't get 1:1 mapping.
Sadly, it is. Many schools, even in third world and fourth world nations, teach English as their second language for people to participate in business with other groups, even other cultures within their same nations. English _is_ the trade language for this era. And compared to the absolute nonsensical debris most speech algorithms generate in poor acoustic environments, human brains designed by evolution and by education to tease speech out of background environments remain the best speech recognition tool.
Why don't they just use these (http://www.sandstorm.net/products/phonesweep/). Amusingly enough, the company sells arms to both sides of the telemarketing conflict, with (http://www.sandstorm.net/products/sandtrap/).
Neither can some humans. Look up 'congenital insensitivity to pain' to see about some people who _cannot_ feel physical pain, but who are, in fact, intelligent people.
Not hard, although it may take longer. Do some jumping jacks: then stop.
Secondary control over your autonomous system counts as 'control', the same way that pushing a gas pedal counts as 'control' of a car. You don't actually need to have your hand on the carburetor to change fuel and airflow, just the more general controls.
I know enough to say: he's mistaken. The tools to image biological structures with sufficient resolution for a '1:1' image would damage them profoundly, even in the setup to make the images. Non-invasive techniques like CT scans and MRI deposit significant energy, the higher the resolution, the more energy, and certainly cannot map to the individual cell or neural junction level. An electron microscope might be able to, but you have freeze it and slice it first.
One may as well say that we can read CD's with a good enough phonograph player, or program your PC with an X-ray machine. You can discover a lot about the layout and overall layout, but many of the properties are also emergent: they arise from having enough components bound together in specific structures that is neither obvious nor directly derivable from the knowledge of the lowest layer components.
They'll try. Like lots of companies making web search engines, Iphone-killers, and other exciting tools, most of them are likely to suck even worse than the current provider: they're vulnerable to the same market forces and the same sorts of middle management, short-sighted fools who helped create GoDaddy at the expense of the rest of the world.
Velcro these days is _necessary_. I've seen far too many "skilled technicians" slice open cables when cutting open Ty-Wraps that have been bundled too tightly, and had fiber-optic fail because similar idiots bent it too firmly Ty-Wrapping it down.
Cable labels are very helpful: 3com makes label dispensers that help, and when you have 3 or 4 network cables on different subnets but all the same color, they're very helpful indeed. They also help sort out old PS/2 cables for mouse or keyboard, number KVM cables, etc.
Power supplies are a problem. Far too many companies use power bricks that plug directly into the socket, and block everything else. For such foolish designes, one-foot power extenders are very useful. Short extenders also useful for USB devices that are supposed to fit directly into the slot, but block other defices. (Wireless USB devices are particularly bad about this.)
Other issues include _not_ stringing power strip onto power strip to provide enough outlets: get strips with longer cables, probably of heavier gauge, and be sure to tie them directly to the wall socket to avoid adventures.
Yes. Steam engines with modern materials are surprisingly lightweight, efficient, and effective, without the complexities of the internal combustion engine.
You've got me on the "head crash" point somewhat. You'd think that a CD laser couldn't head crash, but you've got spinning objects inside boxes with a head that has to move radially, and a lot of them are made amazingly poorly. Mechanical absurdities happen, and the insertion and removal of CD's and their physically open nature tends to allow a lot of debris to accumulate. The result is dust and hair and grit causing mechanical damage: I'm not saying this is a large source of the common damage, but I've certainly seen it in household machines and laptops and poorly maintained server environments. (Company servers shoved in poorly maintained closets, for example.)
And yes, CAV is helpful in many ways: but the random access introduces some fascinating lateral stresses on the mounted reader and potentially writer components, and those darn things _fail_ and do serious physical abuses to discs in the process.
The virtual LAN channel, provided by tools like load balancers, is fine for protecting you from _outside_ access to your internal data channels. But it doesn't do _anything_ to protect you from internal access! This is the hard, crunchy shell, soft chewy underbelly approach, and it remains unfortunately popular. It only takes _one_ malicious internal node. Once a cracker has gotten inside, whether it's an infected laptop connected by VPN, a Windows zombie infected by who-knows-what channel, a VPN connected laptop that you personally use for remote debugging and which happens to have become rootkitted by any means, or a switch that someone else's machine in the datacenter has been able to access due to poor password choice or an unpatched vulnerability, you are _screwed_ once someone else is inside.
The potential vulnerabilities, many of which I've seen personally, are legion. It's why I consider a remote data center, or any environment where I don't personally know and own every single node, to be more like a hotel room: you don't leave the money or jewelry sitting out where someone might be tempted, and you don't leave unencrypted passwords in use _anywhere_.
Good luck with that "understanding". There are plenty of "emergent" properties of complex systems, not predictable from the simpler rules used to create the physical basis of it, but which emerge as the system grows in size, duration, or complexity.
Interesting material on the new Fcgid, thank you for the pointer.
That 'telnet server has only one entry point' is somewhere that you and I disagree. Take a look at a nasty little technique called 'arp poisoning', that can let other devices on your network confuse your switches and get copies of your packets. It's nasty, and a clear proof that running clear text password handling inside a network without _absolute_ control of every node's security leaves you vulnerable to a single compromised server stealing packets from throughout your local network.
There are ways to block it, but I haven't seen anyone in the last 8 years actually bother, in multiple large and small environments.
_Yes_, I understand the technology. No, a rapper does not have to "press" it in a linear fashion: half the fun for a skilled disc jockey at a rap session is tweaking the effects, and that requires dynamic control, not a "pressed" recording. It's the difference between a live concert and a live concert tape.
Moreover, while ideally there is no physical contact, in real live, heads crash. Disks flex, and deform, as they're spun and stopped and spun and stopped. So please do not assume that the wear of a music recording (with several minutes of consecutively recorded music) are handled or physically wear the same as randomly accessed data. That kind of simplification is why people thought CD's and DVD's would last for decades, and why in normal use in real life they last far less.
Well, I personally appreciate that it warns me when people are doing stupid things like telling me, as the web admin and the security admin, that a .htaccess has been set to run CGI scripts out of a local directory, by having them fail outright and provide a log of why they failed. This lets him know that it was a bad idea, rather than proceeding merrily along and proceeding to _think_ about what he's doing, earlier in the process.
Yes, he probably 'abused' it by playing the game. Music CD's have relative simple behavior: they read a track at a time, in a linear fashion, and are unlikely to do hunt&peck data searches. Game CD's are begging to suffer the worst abuses of start-stop usages, for many continuous hours, in a way no music or video media will suffer unless used by a rapper stringing together 3-second segments in strange orders.
Oh, I _wish_ bleeding edge developers would keep such tools up-to-date. It's inherently unstable, though: developments in one package may conflict with those of other packages, in ways that can be nightmarish to resolve. Take a look at Perl's changes in what modules are part of the core Perl tarball, and what are add-ons, to see what such an upgrade can destabilize. So many developers upgrade only those individual components they need, when they need them.
I like to keep a system near the bleeding edge myself, so that I can run into the problem before the developers do and hand them a solution, preferably by sending the bug report upstream and getting it patched in the source itself. But it's a huge timesink.
xa wrote:
> Wait... SELinux is easier to configure than Apache?!!
Oh, dear. SELinux often has working, well-defined structure that programmers are wise to follow (such as keeping CGI tools in the standard Apach location, /var/www/cgi-bin, rather than scattered around your filesystem).
And oh, my, yes, PHP utilities add their own flavor to Apache security. (They basically ignore it altogether: there is a lot of very, very dangerous PHP out there.) It basically has all the delightful power of Perl, but running as the shared 'httpd' or 'apache' user, and with less debugging, and with even less quality control than CPAN provides. It's actually quite frightening to see the utilities people stuff in PHP modules expected to run on semi-public webservers.
I'd be very curous to see guidelines or notes on getting PHP utilities running as their own user. There are some old utilities for managing some shared resources I'd love to see more properly isolated from the 'httpd' user access, and I'd particularly like to provide that for Subversion and git utilities. That's not necessarily PHP, but it's still a good idea to separate the 'httpd' user from the 'svn' user to allow better control of SSH access in parallel to HTTP access to a Subversion repository. I haven't seen any coherent guidelines for that, just huge numbers of webpages which break down to "and then a miracle occurs" in the actual setup.
But telnet use, like the older 'rsh' use on which ssh is based, allows wholesale password sniffing in a way that even flawed SSH servers do not. Guaranteeing that "your network isn't sniffed" is like guaranteeing that your date doesn't have venereal disease. It's just safer to stick with serious protection until you actually have a reason to use telnet, or to want children.
Not quite completely free: RedHat's "RHN" service, for example, takes a paid subscription and is incompatible with non-RedHat clients. Also, their work on "GFS" is not entirely open source, at least at my last review of it, primarily because its original authors had not open sourced it for various reasons.
But RedHat is very good indeed at returning their tools to the free software and open source worlds: they're a model of how to do so and actually add value.
SELinux does help prevent tools from executing in locations or in places that are inappropriate: it helps reduce the destructive capabilities of components that are mis-installed, installed without proper permissions, or that have certain classes of errors. It also helps force you to think before doing something foolish, such as running CGI tools that are not in /var/www/cgi-bin/: it's too easy for foolish people to use .htaccess or poorly handled HTTPD include directives to include some very foolish CGI tools, and I've had SELinux detect this and prevent a fool from running his very dangerous CGI utilities out of his NFS mounted home directory. So it has uses.
Now, that "Jack will never learn to lock it down, so let's not help him so that he has to do it all from scratch himself" message you seem to have is, I'm afraid to say, both popular and insane. Jack _does not want_ to have to learn this material. Jack just wants to have his web site work. Jack doesn't have the time or the money to invest in a long-term career in server security programming: This is a modest tool that can be helpful against some classic errors. (Running CGI utilities out of home directories is my favorite that is blocked by SELinux by default.)
They ruin otherwise working code that was written in slightly different environments, and for which the very arcane behavior of SELinux has not been tuned. They're also often difficult to write test suites for, especially the unpredictability of SELinux changes, since they affect behavior due to factors entirely outside the control of the particular program author: they affect behavior based on where the package installs the code and what SELinux policies are in place.
It's gotten better: Linux operating system authors have gotten more capable with it, and the software authors have learned not to stuff everything wherevery they feel like (with the exception of Dan Bernstein, but he's loosened his licenses, so we can fix that now).