>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

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.

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

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

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

Reply via email to