Re: [PHP-DEV] patch - adds new setting safe_mode_hide_env_vars From: Andi Gutmans (andi <email protected>)
Date: 10/21/00

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 <email protected>
> > > > >For additional commands, e-mail: php-dev-help <email protected>
> > > > >To contact the list administrators, e-mail:
> php-list-admin <email protected>
> > > >
> > > > ---
> > > > Andi Gutmans <andi <email protected>>
> > > > http://www.zend.com/
> >
> > ---
> > Andi Gutmans <andi <email protected>>
> > http://www.zend.com/
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
>For additional commands, e-mail: php-dev-help <email protected>
>To contact the list administrators, e-mail: php-list-admin <email protected> 

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

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>