>I've been thinking some more about the issue of keeping PHP >source files secure in a shared hosting environment. I've now >convinced myself that there is simply no way to protect these >files, even if safe_mode is turned on, as long as other users can >have telnet (or ssh) access to the box. > >Here's my thinking ... > >First off, I am assuming that > - we are discussing a Unix-variant > environment (I don't know enough about > Windows to comment) > - the web server does NOT run as root
To be thorough, you should also rule out: 1. PHP *could* be run as a CGI via suExec as your own user, and thus only if your own shell account was compromised would the file be readable. (If your own shell account is compromised you probably have bigger problems than just the PHP-readable files...) My host actually provides me with both "nobody" Module and "realuser" CGI PHP installation, for example. (http://hostbaby.com -- I highly recommend them -- Apparently they had a hard drive crash last week, but I didn't even notice anything until a cron job ran this week that needed to read/write a file whose permissions didn't quite get restored.) So, if I *really* wanted a particular "secret" secure, I could run it as CGI and keep all my files 400 (or 600 for data) So far, I've used the CGI more for the second stage of file upload (copy into web-tree *ONLY* after security vetting has occurred) but I *COULD* run all the database pages through CGI... And with the minimal traffic I get, I probably should... Oh well. [ASIDE] Too bad I can't run the CGI one first, get a db connection, and then "switch" to the Module one for the rest... Oh, never mind, once you've fired up the CGI, it ain't slower to run. [/ASIDE] 2. I *think* Apache 2.0 *can* be made to run PHP as a Module in different directories as different users... At least, last I heard, that was on the boards for "To Do" in Apache 2.0... So, in theory, as I understand it, there *could* be an ISP who was running Apache 2.0 Beta that was running each users' PHP Module as that user, and your "secrets" files would not be world-readable. 3. I'm reasonable certain fhttpd has the same feature as described in 2. That said, some more caveats about file browsing: I *THINK* you can bury your PHP file inside directories that are not readily browsable by other shell accounts. So long as the "foo.inc" file *is* readable, the intervening directories don't have to be. I *THINK*. I got bit by this once on one web-site, but I was mixing and matching a Module and CGI usage (see 1.) and maybe was just confusing myself about which user was actually 'acting' at a particular time. >So unless I'm missing something, safe_mode provides no protection >in a Unix environment where > - the web server does not run as root > - other users have telnet access to the box > >I hope wrong. Can anyone find the hole in my reasoning? Safe mode stops some of the most obvious routes of reading the files in question -- It doesn't stop a determined reader from digging them out and reading them. As noted earlier -- If a real hacker *really* wants to break in, they will. Usually, your task (and the ISP's) is to raise the bar high enough that the frequency of successful attack is low enough, that you/they don't spend your/their entire life restoring from un-hacked backups. There are some high-end special cases where your task is far more complicated than that, of course... To that end, less-obvious file names and safe mode "weed out" some percentage of the "wannabe hackers" If truly secure "secrets" are needed, a shared environment is the wrong answer... The same shoe doesn't fit everybody. I generally prefer systems where I don't feel hamstrung every time I need to do something interesting with my web-sites, and I'm willing to risk the (mostly public) data in my databases being compromised by fellow clients of my ISP for that. I'm also mostly on servers with starving musicians who have a hard enough time getting their web-sites to work and getting gigs, much less time to waste pawing through my files :-) In one extreme case, the bulk of the data is editable by anybody on the planet through a web-interface, so "securing" the username/password would be almost pointless. I still do it, through habit and to avoid mass destruction by the unwashed masses, but... Security is not an on/off switch. It's a gradient in N dimensions, where you have to balance usability, development time, risk, upper management stupidity, and a host of minor variables to decide where your software/hardware/solution "fits" into the spectrum. You can't learn that in one day, or even in a week's seminar. It's a place where experience counts. I'm not saying a one-week security seminar wouldn't be invaluable -- only that the seminar has to be followed by a lot of real-world experience to be really useful. I've picked up (mostly against my will) enough knowledge about security to know how truly ignorant I am :-) But even I know enough to be worth listening to maybe, eh? -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
