On Wed, 19 Dec 2007, Drew A. Withers wrote: > Dan Mahoney, System Admin wrote: >> On Mon, 17 Dec 2007, Drew A. Withers wrote: >>> It is true that suphp has no problem when the php file in question is >>> world-readable, but we don't want all php files to be world readable. >>> That doesn't make much sense. >> >> Sure it does. >> >> Let's look at the most oftenly exploited code I have on my box (phpBB). >> >> The scripts themselves are world-readable (and who cares, if someone >> wants to read the source to look for exploits, they can just download a >> copy). >> >> However, I carefully chmod any script that is *included* (i.e. the >> config.php) to mode 600 (since that's where the DB login is. That file >> never gets directly run by either the webserver or suphp, but simple >> "included" by the user code, which is already running as the user at >> this point.
Warning. This isn't going to be pretty. > Our users won't necessarily be using just open source projects. Also, we > can't expect all of our users to be aware of these security issues. They > don't all know how permissions work. Then what the hell are they doing allowed to upload to a unix webserver? Should they just trust the docs that say "chmod everything 777" (Yes, Zencart, and others tell you to do exactly this). > And those writing their own code > will likely wonder why they have to allow the world to read their code. ..because that's what they'd have to do on any other non-suPHP'd webserver? suPHP doesn't change this behavior. or maybe: For the same reason they have to let the whole world read ANY OTHER FILE that apache's going to serve -- from cgi's to favicon.ico? Go ahead and see how well apache works on any site, at all, with all the files chmodded 0600, or where the entire path to the site doesn't at least have 001 permissions. Will your users also complain that they don't know why "everyone" should be able to search their home directory? (since that's what the o +x bit implies in many FTP clients?). Take your FTPd/SFTPd, and set their umask accordingly, and be done with it. Drop educational things into /etc/motd and into your policy documents. And put a permission-fixer into your daily maintanance tasks. Have it email your stupid users and encourage them to ask for help, as once someone shows them the "proper" boxes to check in their client, they probably will always do that, or will always get emails. If they continue to fail, modify the code to drop a "Deny From All" in their directory. Running suPHP is only HALF the fix if your users chmod their stuff as world-writable. Those too stupid to understand security shouldn't be allowed to write their own code. Those too stupid to understand "critical flaw, upgrade now". Or "This code is no longer supported or recommended because of numerous security flaws" (phpFanBase) is the reason I *run* suPHP -- but even then, in the case of a phpBB exploit, I'd found a worm had overwritten every OTHER file that was chmodd'ed too permissively (which is the inverse to your argument, which is to say, chmodd'ed not permissively enough). Even then, suPHP only makes it easier to tell *which* of your users uploaded the bad code...code as easy as: URL: index.php?page=main PHP: include $page.php suPHP won't stop your users from uploading it, nor will suPHP stop PHP from using the above code to download a trojan from somewhere. All suPHP will do, is suddenly make it obvious which UID is suddenly spamming guestbooks and becoming a botnet node. Seriously. If you can't at least *attempt* to educate your users, please don't tell us why it's a problem. -Dan -- "If you need web space, give him a hard drive. If you need to do something really heavy, build him a computer." -Ilzarion, late friday night --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- _______________________________________________ suPHP mailing list [email protected] http://lists.marsching.biz/mailman/listinfo/suphp
