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?


----- Original Message ----- 
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
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

PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to