[PHP-DEV] Re: safe_mode redesign

[Jason Greene]

Zeev,

I see your point. Would you accept changing safe_mode to restrictive_mode,
and refer to features as what they really are? 

For example: 
restrictive_uid_check = yes
restrictive_purge_environment_vars = ( )

There could be a page on php that explains all the various modes, functionality, etc...
We could then of course state that this is not intended to replace OS security.

> Also, be advised that many functions don't use the APIs, but use system 
> calls directly.

I thought everything went through TSRM?

-Jason




- Original Message - 
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, February 06, 2001 5:36 PM
Subject: Re: safe_mode redesign


> 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, 
> >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
> 
> 


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: safe_mode redesign

[Dennis Youngblood]

"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, 
> >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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: safe_mode redesign

[Stanislav Malyshev]

ZS>> My point is that with safe_mode, $x = file("/etc/passwd") can probably
ZS>> still be achieved, only perhaps not that easily.  The false sense of
ZS>> security that it gives you may (will) cause administrators to set their
ZS>> servers up in an insecure way.

Here I wonder, why it is impossible to define some set of safe mode
security guidelines, and make all functions conform to it? After all,
mostly everything (except, probably, some extensions like COM when you
never know) is controlled by the engine, why isn't it possible to have it
to adhere to some set of guidelines?
Also, if the guidelines would really be defined and documented, the
sysadmins would know what it actually does and what it does not, not
basing on the word "safe" alone.

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: safe_mode redesign

[Boian Bonev]

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, 
> 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
>

[PHP-DEV] Re: safe_mode redesign

[Zeev Suraski]

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, 
>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


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: safe_mode redesign

[Jason Greene]

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, 
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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: safe_mode redesign

[Sander Steffann]

Hi Zeev,

>-- Quoted from Zeev:
> 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.

I agree. I think this means that either:
- We shouldn't do very much on security
- We should make clear we are NOT providing complete security, but that we
only try to help the administrator by giving him some extra options.

> 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...

I know :(

Maybe we could make a document that describes what a module/extension should
do to be considered 'safe-mode compatible'. That way it would be easier for
the module author to check his code. I don't believe anyone is intentionaly
writing 'insecure' code.

Sander.



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: safe_mode redesign

[Zeev Suraski]

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]