Re: safe_mode redesign
| From: | Zeev Suraski | Date: | Tue, 06 Feb 2001 23:36:56 +0000 |
| Subject: | Re: safe_mode redesign | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-45899@lists.php.net to get a copy of this message | ||
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