Dan Mahoney, System Admin wrote: > Warning. This isn't going to be pretty.
First of all, I am only somewhat familiar with the full functionality of suphp. So give me a break. >> 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. Second of all, normally (without suphp) php reads and executes files as the apache user, so php files do not have to be world readable, just rx by the apache user (either as an owner or group member). This permission is taken care of by our nfs server. It has a policy that allows a specific uid to access the www directory of every user. Therefore the files only have to be owner/group readable (therefore 750/550 permissions would suffice). > 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? We use suexec to run cgi as the script owner as well, and therefore our cgi scripts do not have to be world readable either. > 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. With our current setup, (using an old employee's hacked suphp) we are able to execute php with 550/750 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. Agreed. But that isn't exactly up to me. > 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. This is a college site that offers web accounts to students. We don't intend to try and fix every security flaw that they may put on their web space, we only wish to protect those who do know what they are doing with their permissions but are unable to turn off world read/execution of their scripts. We realize suphp may not be the ideal solution for our situation, but as an upgrade of our servers is eminent we are looking for a similar solution to what we have now. I want to know how web hosting companies take care of this issue. For example 1and1.com, the company that hosts my site, executes all of my php code as my user. This is what we want with suphp. -- Drew A. Withers <[EMAIL PROTECTED]> Assistant CAEDM CSR Brigham Young University _______________________________________________ suPHP mailing list [email protected] http://lists.marsching.biz/mailman/listinfo/suphp
