Re: safe_mode redesign

Zeev, I see your point. Would you accept changing safe_mode to restrictive_mode, and refer to features as what they really are? For example: restrictive_uid_check = yes restrictive_purge_environment_vars = ( ) There could be a page on php that explains all the various modes, functionality, etc... We could then of course state that this is not intended to replace OS security. > Also, be advised that many functions don't use the APIs, but use system > calls directly. I thought everything went through TSRM? -Jason ----- Original Message ----- From: "Zeev Suraski" <zeev@zend.com> To: "Jason Greene" <jason@inetgurus.net> Cc: <php-dev@lists.php.net>; <andi@zend.com> Sent: Tuesday, February 06, 2001 5:36 PM Subject: Re: safe_mode redesign > At 21:53 6/2/2001, Jason Greene wrote: > >Zeev, > > > >I understand your viewpoint, but I respectfully disagree. I believe that > >there are multiple levels of security, and that the OS is > >just part of the picture. There always is some layer of application > >security(especially for those apps that run id=0). If you are a > >hosting company ( which is becoming a very large business), then you > >desire a way to provide your customers with a programming > >interface that does not infringe on other customers, or your systems > >security. Without a safe_mode, <? $x = file("/etc/passwd"); ?> > >is still allowed. > > My point is that with safe_mode, $x = file("/etc/passwd") can probably > still be achieved, only perhaps not that easily. The false sense of > security that it gives you may (will) cause administrators to set their > servers up in an insecure way. > > >It seems that your biggest concern is giving users a false sense of > >security. This feature is something that would not be used by > >the average user. The people who would mainly be using this would have an > >ok knowledge of security, and if you have an ok knowledge, > >then you will know to Never Trust Anything > >There is always a possibility of security methods being penetrated, > >everyone just has to be made aware that security is just > >something that rules out the majority of breach attempts. That is why you > >need multiple levels > > > >I believe that performing something similar to a chroot in the lower level > >file operations, would lock php itself into a protected > >area. PHP is very modular, and has an excellent lower level API., both of > >which makes this a very possible thing. > > Well, I respectfully disagree :) One thing we haven't done, is telling > people one clear statement - 'Safe mode is NOT secure'. It's a functional > feature, not a security feature. It hasn't been audited, and God knows how > many bugs and loopholes lurk in the dark (my guess - many). > I don't mind seeing an impressive safe mode being implemented, as long as > it's presented as a functional feature, with the appropriate disclaimers > telling people that this does *NOT* replace security measure that they > would otherwise use. > > Also, be advised that many functions don't use the APIs, but use system > calls directly. > > Zeev > >