On Wed, 19 Dec 2007, Drew A. Withers wrote: Apologies by the way if that came off way too flamish, by the way -- that wasn't my intent at all. I've been doing this a while and the more I do it, the more I realize that I *have to* support the language of badly written easily-compromisable scripts, for competitive reasons. But I don't have to like it.
I'm going to try and keep my rant tone minimal and try to offer decent advice here, coupled with my guesses at the "way things really are". > First of all, I am only somewhat familiar with the full functionality of > suphp. So give me a break. > 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. SuExec's logic is largely the same as suPHP's (suphp was inspired by SuExec), and I would believe suexec would have to do similar stat() calls before doing this. Read the code and see. Even if you don't speak C, you can figure out what happens first. Apache may do those tests as itself before calling the suExec wrapper to run the script, or the wrapper may do it. >> 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. A stock apache won't work that way, which is what my original (somewhat ranty) advice was based on. That's a hack provided by your NFS server, as well. Unless you're somehow telling me that the webserver-user is in the same group as your regular users. Based on what you've told me unless I have it terribly wrong, you couldn't use the same policy WITHOUT nfs -- i.e. apache running on the server "with the disks". (Unless you did some local filesystem ACL hack to somehow make your filesystem more permissive than regular permissions allow. If this is the case, your users aren't likely aware of it, which means you're misleading them and they'll think they did something wrong when they get to the "real world" and have to chmod their files world-readable). Note: I also don't know your permissions model. Based on what I use, every user has their own group. Your group may be "students" and "staff" and the webserver-user may be in that group. The model I use is the only thing that makes sense for ME (classic unix permissions, nothing more), otherwise, group-writable is just MORE dangerous than world writable (because it doesn't throw up as many red flags as "OMG 777!"). > 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. I should also mention that cpanel and plesk have their own bastardized versions of suPHP and SuExec -- which are similar. 1and1 may have contracted their own changes. And I'm sure they wouldn't share the details...gpl be damned. As an aside, I've been (and have had cabinet space) in one of 1and1's datacenters -- (they lie to their customers like everyone else in this industry) about who can get access to them, and while there was a "cage" around the machines, it was in an unmanned datacenter where something as simple as a CHAIR could have circumvented their careful security. :) They also have c-coders on staff who can understand this stuff in ways I can't, and they can do things like mess with the only ftpd's they support so it will, for example, force files to the right masks/modes. The above philosophy of saying "yes, o+w" is how I do it, as well as my rather draconian design philosophy. If you want a shell account (or even a subdomain hosting account) let me know and I'll provide one. I'm all in the interest of education (both of admins and users). Presumably you're also a college teaching web-design classes. Maybe (like my school was) you're even teaching web-design classes by a tired adjunct who's going to ignore any memos about system security and instead tell people to do whatever. If it's actually a PHP programming class, well, that's harder :) Quite possibly that tired adjunct will be an old mainframe guy who just read Sam's Teach yourself PHP in 24 hours to pick up an extra semester's revenue, and has no idea of the wealth of issues surrounding this stupidly-popular (or popularly-stupid) language. My answer in your shoes (though sadly, probably not yours) would be "sorry, we don't support PHP". Sadly, you probably like your job. Or at least need the money... Which brings us back to why *I* run php at all :) Other things to consider: * Do a quick google search for url_allow_fopen -- and see if you can limit that site-wide via your php.ini so that at least your users who are writing "my first PHP script" can't be exploited QUITE so easily. I do *NOT* but for a college you could get away with it. * periodically scan for 777 directories in "user directories" and warn/fix * periodically scan 1777 directories (/tmp, /var/tmp) for files with a ctime which greatly differs from atime. * periodically scan the above with use of "file" to detect executables. * Periodically look for longer-than-usual-running processes. Pop a LSOF on them and investigate manually. * Periodically (get the idea?) grep your suphp log for the failures... * Periodically search for php.core and suphp.core... * Periodically scan user directories for files they do not own... -Dan -- --------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
