Re: Re: safe_mode redesign

"Zeev Suraski" <zeev@zend.com> wrote in message news:5.0.2.1.2.20010207013138.01ab12f0@mail.zend.com... > 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