Re: patch - adds new setting safe_mode_hide_env_vars

Changing TSRM to have the ability to prepend a directory is simple. It is probably one of the stronger ways to really enforce a chrooted enviromnent. But it does mean that PHP would be in a complete virtual root and I am not quite sure just how much it would effect all the different parts of PHP. So the idea is that you would add in php.ini where your PHP virtual hosts are kept, for example, /php_users/ and the directory functions would use the virtual hostname (SERVER_NAME) to index it? Actually I'm not sure what exactly would be right to use. Andi At 01:57 PM 10/21/00 -0500, Jason Greene wrote:

In answer to your questions(sorry that this is long), a) centrilize safe_mode (like open_basedir was) I do agree with centralizing safe_mode as much as possible b) make sure safe_mode really works Unfortunately allowing users to be developers in safe manor is difficult. Alot of applications have battled with things such as this for quite awhile. Unix uid security is good, but it can't catch every little thing, and there are obvious problems as it was not designed for untrusted developers. A common solution, that is very effective , is chrooting (ftp for example) If users have a virtual area, then they can only mess with there own environment. In order to secure cgi my team (at work) modified suexec to perform a chroot before every call to a program. Then for users to share data(ex. their own /usr/bin) we would create there mini-environment with hard links. Achieving this as a server side module is even harder, but php currently has hooks in place for this. fopen-wrappers and TSRM completely seperate the module writter from the system call, so all that is really needed is to just expand them a little more. One idea I had on this would be a virtual_jail directive which would work similar to apache's virtual_document_root directive. For example you could say safe_virtual_jail = /sites/%1.1/%1.2/%0/jail/web/ this would translate to /sites/m/y/www.mysite.com/jail/web and all fopen calls could be limited to that area then users can say fopen("/data1.file") and they really open /sites/m/y/www.mysite.com/jail/web/data1.file then the error callback would have to be sure to display the virtual file /data1.file, instead of the full path For modules like gd, hard links could be used, or for those who don't like that method, or those on win32, perhaps a shared data directive that doesnt care about uid With this method, the module writters would trust fopen-wrappers to take care of everything. I believe this would definately be a "safe" mode We can give the tools, but no matter how this is done, there is going to have to be a good manual section to explain all the options What are your views on this? -Jason Andi Gutmans wrote: Oh, OK. In that case, it does sound reasonable. I still would like to move some of the other safe_mode stuff (like checkuid()) to a more centralized place such as php_fopen_and_set_opened_path() (I moved open_basedir there) but there are some issues such as in the GD module where you do want to allow the developer to open certain files even if they aren't under his uid. This whole safe_mode issue is a very complex issue and I don't know easily we can: a) centralize it more b) Make sure everything is safe_mode'ed and works the way it's supposed to. Right now I tell people that I don't consider safe_mode as being completely "safe". Andi At 11:57 AM 10/21/00 -0500, Jason Greene wrote:

I did think of that, safe_mode blocks all capibility to execute commands ( backtics, passthru, exec, system, etc ) -Jason Andi Gutmans wrote:

What if someone does exec("printenv") ? He can still get all of the environment variables. Andi At 04:35 PM 10/20/00 -0700, Jason Greene wrote:

If you guys could take a look at this patch, and see what you

think. This

allows for an ini setting that will block specified environmental variables from being seen by php scripts. It does

make one

update that probably should be moved, and that is in php_module_startup. Since this uses a hashtable datatype,

zend_hash_init

needs to be called. You guys probably don't want this in the main startup, but I figured that you could let me know where

it could

go best. Maybe a startup call in safe_mode.c? I know we had discussions about doing an env -i before running

apache, and

I do agree on cleaning the apache users environment, but there is always the possibility of env vars you can't remove. (LD_LIBRARY_PATH) . If you like the idea, but want things in different places let me know -Jason -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail:

php-list-admin@lists.php.net

--- Andi Gutmans <andi@zend.com> http://www.zend.com/

--- Andi Gutmans <andi@zend.com> http://www.zend.com/ -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

--- Andi Gutmans <andi@zend.com> http://www.zend.com/