hi,
here is something i have posted some days ago:
....or better if you have untrusted users who shall have php access, give
them
cgi php and use apache's exec wrapper to setuid to user's uid and chroot to
her home dir.
if their count is not too big run their own web servers under their uids and
again chrooted to their home dirs. this is the best solution i know of.
...
most of the shared hosting environments at least allow one user to access
another's files. not mentioning system access, etc.
a safe_mode will not help in these cases - like named buffer overruns a
safe_mode hole will be discovered weekly.
i am running both configs since apache1.2/php3.0.5 and except performance
issues i have seen no other drawbacks...
b.
----- Original Message -----
From: "Jason Greene" <[EMAIL PROTECTED]>
To: "Zeev Suraski" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, February 06, 2001 9:53 PM
Subject: [PHP-DEV] Re: safe_mode redesign
> 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]
>
>
--
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]
