As I said, I think a script which audits the permissions and suggests and makes changes would go a long way.
This assumes we think there should be changes from the default shipped by Debian or Red Hat, and, in general, we don’t.
I’m of the long-held opinion that most “hardening” scripts are mere hand-waving and blowing smoke. I don’t want to be among those snake oil salesmen who sell empty promises in the guise of security.
Re chroot in most cases I think not allowing shell access is the best, but getting php fastcgi running inside a chroot jail could be the ultimate answer to the issues I raised here - an article at http://www.seaoffire.net/fcgi-faq.html describes how to do it in detail - maybe something for the future?
As I mentioned, chroot simply was not designed to be a security tool–using it as a security tool is, once again, a bit of smoke and mirrors. It’s not improving security. It’s hiding a few bits of detail about the system to casual investigation…but also opening up potential serious security issues (like the fact that the chrooting has to be initiated by a root-level user…so if it is exploited, it is far more likely to be a root-level exploit, which means you lose everything in then event of a security hole, rather than just one virtual server).
I think you’re misinterpreting my brief answers: My point is not that security doesn’t matter to us, or that it shouldn’t matter to you. We are deeply concerned about security of Virtualmin, Webmin, Usermin, and the services that our products manage.
It’s that what has been presented as security so often in the web hosting world, is in fact one or both of the following:
Dangerous by design (like using chroot as a security tool)
A pointless waste of time (like fretting over a user having read access to passwd or httpd.conf)
The things that contain sensitive information should be locked down–and they pretty much are, by default, on a RHEL/CentOS or Debian system.
I don’t want you to think we’re merely waving off security as an unimportant concern. We’re not. It’s that we’re trying to prevent our customers (whom we like, and wish the absolute best in their experience with our software and the servers they manage) from either making dangerous mistakes (like thinking chroot is a security feature, when it is just as likely to be a security hole, and an extremely serious one) or wasting their time fretting over things that cannot be prevented in a shared hosting environment (e.g. if you give me the ability to upload arbitrary files to a web hosting account on pretty much any UNIX/Linux system, regardless of whether I have a shell, and I can get the contents of /etc/passwd–no matter what you do to PHP or fcgi…but, that’s OK, because UNIX was designed that way, and it’s not a security issue…/etc/shadow would be a big problem, but I can’t get that, even with a shell).
I’m not advocating the use of safe mode in PHP or basedir. I’m not opposed to them, per se, but I don’t consider them mandatory and I don’t use them on the systems I manage, including those with shared hosting users. (Though, the less trusted your users are, obviously, the less privileges they should have. basedir might be a good compromise for many classes of nosey but not very UNIX literate users…it won’t stop those users that are literate, though.)