"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 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.
Unfortuneately, those same administrators right now, just decide that they
will install it anyway, and then people will start to hear about how easy it
is to "hack" php servers (because the general public just doesn't understand
what is REALLY going on). Or, even WORSE, these administrators, seeing very
LIMITED security featureset VERY similar to mod_perl, decide that PHP is not
designed for multi-hosting, so the general public will most likely never be
truely exposed to it.
> >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
Then perhaps this is something that should go to the drawing board for the
next major version of PHP (5?). I agree with you, in that SAFE mode is NOT
secure.... rather it is SAFER mode. Still, you have to admit, that SOME
security is better than NONE. I also believe that multiple layers of
security, no matter what system you are administrating, is a NECESSITY....
you can't trust your apps, and you can't trust your OS, so, you have them
both watch each other.
Whether it is designed in, or struggling administrators hack it in, it WILL
get in there. I propose that the term SAFE_MODE, and all of its functions
be replaced with multiple WRAPPERS. We have fopen_wrappers. We can further
enhance fopen_wrappers to tweak things like UMASK and multi-hosted
open_basedir (/home/domains/*/htdocs). I also agree when you say that
according to the current version, we cannot say that safe_mode means safe
for all modules. This will require a redesign, with a security layer that
all modules will have to plug into. I realize this is a major rewrite, but
it is necessary to ensure that PHP doesn't fall like mod_perl did (it is a
great feature, but it makes the server insecure, so hosting providers either
didn't allow it, or they do, and they pray).
Dennis Youngblood
Web-Hosting Administrator
RCS Internet
www.rcsis.com
916.772.5014
--
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]
