Well, I'm sorry to wait so long to repond back to this. I picked the wrong week/month to start this discussion as I didn't have the time to follow up on it. Now I kinda do.
A lot of good and bad (IMHO) points were raised about PHP security in this thread. I am concerned about any one of my users being able to read another user's files, database passwords, etc. I try for 100% security. When I said 100% security before I meant that by concept there are no holes. I know that I can't expect Apache/PHP to be 100% secure because there are other issues. But those are usually not by design and can usually be fixed with a patch. What I myself will probably choose to do is look into mpm_itk as a way to control the whole "Users shouldn't be able to access other user's files" problem. Maybe it will introduce more holes, who knows. But when I impliment a service, I thoroughly test it for holes because I can't trust the developers to have done things right. Don't believe me? Here (http://lwn.net/2001/0208/a/sec-chilisoft.php3) is an example of me being more thorough than most people. I did the same thing with PHP a while back. I went through and made sure that I had a setup by design that prevented users from reading other users files. This setup included applications on the server across the board, not just PHP. And the best solution I could find for securing PHP was to put PHP in safe mode and use safe_mode_execdir to prevent users from running arbitrary programs. Perchild MPM never made it and eventually became a moot project. Metux tried to follow in the same shoes but is also failing for the same reasons (dealing with SSL). Maybe mpm-itx's approach will work, but it might not work for everyone. If you could just provide a way to prevent users from executing arbitrary programs, I'd be happier and it would solve some issues. Right now even with open_basedir turned on and safe mode off, its trivial for a user to upload the 'cat' program to their account and then run this script: <?php print exec('/home/myuser/www/cat /home/otheruser/private/mysqlinfo'); ?> See what I'm getting at? File ownership checking is just one part of safe mode, exec dir restrictions are another major part. If you remove this, it will open up a whole can of worms. Some people are going to say that the solution is to disable all the execution functions, but tell that to joe user who wants to be able to run some popular photo gallery software or blog that needs to run an external command like ImageMagick. Of course even if you did add some execution directory restriction that is not part of safe mode, you'd still be vulnerable to people being able to use arbitrary arguments to the restricted programs, but that only works if you can exploit the programs, so it provides some safety. Some people say to run Apache in a chroot jail, but I think that's unreasonable and a lot of people aren't going to do that or know how to do that properly. Besides, am I really going to run 200+ instances of Apache? That seems unreasonable. Unless there is some other way in PHP of restricting where you can run programs from (can't find any), this is going to become a major problem. Many web hoting providers are already insecure (http://suso.suso.org/xulu/Web_hosting_providers_with_poor_security), this will just make many more insecure as well. Even the ones that try at least somewhat to protect themselves. Mark On Mon, Aug 27, 2007 at 05:59:16AM GMT, Rasmus Lerdorf [EMAIL PROTECTED] said the following: > Mark Krenz wrote: > > ??? What do you mean? I talked with Ryan Bloom about this at Apache > > Con 2000 and he said that with Apache 2.0, modules would be able to run > > code with the permissions of the user assigned to each vhost. I asked > > about the prospect of PHP being able to utilize this and he said its > > possible, but I got the impression that the PHP devs where not > > interested. > > This is the perchild MPM. It was supposed to allow you to configure a > given number of threads per user, which in your case would mean per > virtualhost, and it would route requests correctly to these pools of > threads. If you had done a bit of reading on the history of the > perchild MPM since 2000, you would have discovered that it was never > completed and it is no longer part of Apache2. The concept looked sort > of ok on paper, but it had a number of problems. On the PHP side the > main drawback with it was that it required a threadsafe environment. > Back in 2000 most of the libraries PHP could be linked against were not > threadsafe, and even today it is rather risky to run in threaded mode if > you link in a lot of 3rd-party libraries. A small dedicated server with > a limited number of extensions can run quite well threaded, but in an > ISP situation where you basically have to link in everything under the > sun, getting everything stable and robust in a threaded environment is > painful. > > You will never get a 100% secure web server. It just doesn't happen. > The best you can do is use a layered approach where each of your layers > act at different levels and hope that the holes in each of your layers > don't all line up. Think of it as using 3 innertubes in a tire each of > them with a couple of holes in them. You'd have to be pretty unlucky to > have a leaky tire. But in order for this to work the layers have to act > on different levels and they have to all be trying to achieve one thing. > > In our case, what we are trying to achieve is to prevent external users > from exploiting flaws in PHP or in userspace code to attack the server > or the application. Safemode doesn't fit this. Safemode was a > misguided attempt at providing some sort of protection against malicious > users on the same server. There are no layers to help us here, and it > has multiple known holes, so the tire is always flat. > > PHP is the wrong level to try to protect users from other users on the > same server. No language does this. You brought up Perl, for some > reason. It also has absolutely no way to protect two perl scripts that > run as the same user id on the same server from mucking with each > others' files. I added safemode to PHP years and years ago when it was > a much simpler beast. I'm not (always) an idiot, and I knew at the time > that it wasn't the right place to add this protection, but the > alternatives at the time weren't viable, and I needed it. It was even > somewhat effective since it has less things to deal with. As PHP grew > and became more complex and linked in more complex libraries, it became > completely impossible to even begin to pretend that safemode was still > effective. Any 3rd-party library that accesses files are not subject to > the safemode check unless we can somehow catch it at the PHP level. For > stuff like the Oracle client library where an sql query can open a file, > and that query can be written a hundred different ways, there is > absolutely no way to make safemode work. We don't have the source code > to this library and there are no hooks for us to override file access in > it. I appreciate that you think we should just solve these problems and > make safemode perfect because that would make your life easier, and I > appreciate, well I don't actually, that you think we are idiots for not > doing so, but while we may be idiots, we have actually thought about > this quite a bit, and we consider it an intractable problem. > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
