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" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[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]
