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

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>