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.
While the details get tricky, and sometime complex, the overall concept is simple.
Before any risky activity is performed, check the
list of things to block. There are tons of applications out there that perform these
kind of important checks. ProFTPD is a good
example of one such application. It allows you to lock users into certain areas, use
specific uids etc.
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.
I have spent quite a bit of time customizing PHP to work well in a secure environment,
and I have seen other service providers doing
the same thing. The problem is that ppl are still going to do this whether its part of
the codebase or not. If all of this work was
combined, then it can be shared, repaired, and optimized by everyone.
A safe programming chapter could be referred to in documentation as "An experimental
security option designed for ISP and hosting
providers. This is by no means the finality of security, just a tool to help
in developing a secure environment"
Thanks,
Jason
----- Original Message --
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
ACc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, February 04, 2001 6:43 AM
Subject: Re: safe_mode redesign
> Jason,
>
> The one main problem with safe_mode in general is that the idea is
> problematic by definition. Security outside the OS level is prone to
> errors, and a false sense of security is much worse than knowing you're
> insecure.
>
> In my opinion, safe mode should only feature features which can have an
> infrastructure-level solution, and are not prone to errors. There aren't
> too many of these. The current safe mode implementation is extremely prone
> to errors because it tries to protect opened files, and the way its built,
> it's bound to be missing checks in many places...
>
> Zeev
>
> At 22:53 1/2/2001, Jason Greene wrote:
> >Is anyone up for a discussion on the redesign of safe_mode? I would like
> >to start working on this sometime soon, and I have a lot of
> >ideas, but I know this is going to be something of a large debate.
> >
> >Some of the new features I think would benefit php include:
> >
> >* safe_mode_hide_env_vars - will allow extra protection on removing
> >environmental vars from hosted users ( I actually have a patch
> >for this but I have been waiting on it to discuss the redesign)
> >
> >* User configurable policy - safe_mode could have configuration directives
> >to specify exactly what checks are desired
> >
> >* Virtual Chroot - the ability to perform a chroot to a virtual host
> >directory structure, so that a hosted user can not access
> >anything outside of their directory structure.
> >
> >* Shared Directories - The ability to specify a list of paths that are
> >shared amongst all hosted users. This would allow certain
> >extensions (gd, oracle, etc) the ability to access the needed datafiles
> >without failing a safe_mode check.
> >
> >Any comments, suggestions, other ideas?
> >
> >-Jason
>
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
>
>
--
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]
