Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Mark Krenz

  Well, I'm sorry to wait so long to repond back to this.  I picked the
wrong week/month to start this discussion as I didn't have the time to
follow up on it.  Now I kinda do.

  A lot of good and bad (IMHO) points were raised about PHP security in
this thread.  I am concerned about any one of my users being able to
read another user's files, database passwords, etc.  I try for 100%
security.  When I said 100% security before I meant that by concept
there are no holes.  I know that I can't expect Apache/PHP to be 100%
secure because there are other issues. But those are usually not by
design and can usually be fixed with a patch.

  What I myself will probably choose to do is look into mpm_itk as a way
to control the whole Users shouldn't be able to access other user's
files problem.  Maybe it will introduce more holes, who knows.  But
when I impliment a service, I thoroughly test it for holes because I
can't trust the developers to have done things right.  Don't believe me?
Here (http://lwn.net/2001/0208/a/sec-chilisoft.php3) is an example of me
being more thorough than most people.

  I did the same thing with PHP a while back.  I went through and made
sure that I had a setup by design that prevented users from reading
other users files. This setup included applications on the server
across the board, not just PHP.  And the best solution I could find for
securing PHP was to put PHP in safe mode and use safe_mode_execdir to
prevent users from running arbitrary programs.  Perchild MPM never made
it and eventually became a moot project. Metux tried to follow in the
same shoes but is also failing for the same reasons (dealing with SSL).
Maybe mpm-itx's approach will work, but it might not work for everyone.

  If you could just provide a way to prevent users from executing
arbitrary programs, I'd be happier and it would solve some issues.
Right now even with open_basedir turned on and safe mode off, its
trivial for a user to upload the 'cat' program to their account and then
run this script:

?php
print exec('/home/myuser/www/cat /home/otheruser/private/mysqlinfo');
?

  See what I'm getting at?  File ownership checking is just one part of
safe mode, exec dir restrictions are another major part.  If you remove
this, it will open up a whole can of worms.  Some people are going to
say that the solution is to disable all the execution functions, but
tell that to joe user who wants to be able to run some popular photo
gallery software or blog that needs to run an external command like
ImageMagick.  Of course even if you did add some execution directory
restriction that is not part of safe mode, you'd still be vulnerable to
people being able to use arbitrary arguments to the restricted programs,
but that only works if you can exploit the programs, so it provides some
safety.

  Some people say to run Apache in a chroot jail, but I think that's
unreasonable and a lot of people aren't going to do that or know how to
do that properly.  Besides, am I really going to run 200+ instances of
Apache?  That seems unreasonable.

  Unless there is some other way in PHP of restricting where you can run
programs from (can't find any), this is going to become a major problem.
Many web hoting providers are already insecure
(http://suso.suso.org/xulu/Web_hosting_providers_with_poor_security),
this will just make many more insecure as well.  Even the ones that try
at least somewhat to protect themselves.


  Mark

On Mon, Aug 27, 2007 at 05:59:16AM GMT, Rasmus Lerdorf [EMAIL PROTECTED] said 
the following:
 Mark Krenz wrote:
???  What do you mean?  I talked with Ryan Bloom about this at Apache
  Con 2000 and he said that with Apache 2.0, modules would be able to run
  code with the permissions of the user assigned to each vhost.  I asked
  about the prospect of PHP being able to utilize this and he said its
  possible, but I got the impression that the PHP devs where not
  interested.
 
 This is the perchild MPM.  It was supposed to allow you to configure a
 given number of threads per user, which in your case would mean per
 virtualhost, and it would route requests correctly to these pools of
 threads.  If you had done a bit of reading on the history of the
 perchild MPM since 2000, you would have discovered that it was never
 completed and it is no longer part of Apache2.  The concept looked sort
 of ok on paper, but it had a number of problems.  On the PHP side the
 main drawback with it was that it required a threadsafe environment.
 Back in 2000 most of the libraries PHP could be linked against were not
 threadsafe, and even today it is rather risky to run in threaded mode if
 you link in a lot of 3rd-party libraries.  A small dedicated server with
 a limited number of extensions can run quite well threaded, but in an
 ISP situation where you basically have to link in everything under the
 sun, getting everything stable and robust in a threaded environment is
 painful.
 
 You will never get a 100% secure web server.  

Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Cristian Rodriguez
2007/11/5, Mark Krenz [EMAIL PROTECTED]:

   Unless there is some other way in PHP of restricting where you can run
 programs from (can't find any),

Why PHP needs to do that ? isnt that part of OS level security ?

this is going to become a major problem.

This is going to **solve** a major problem, this change will eliminate
the false sense of security that safe_mode provides and will tell
people to start securing their stuff better.

safe_mode does not really resist any analysis, whoever convinced you
that it is a good thing does not have a clue.



-- 
http://www.kissofjudas.net/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Alexey Zakhlestin
On 11/5/07, Mark Krenz [EMAIL PROTECTED] wrote:
   Some people say to run Apache in a chroot jail, but I think that's
 unreasonable and a lot of people aren't going to do that or know how to
 do that properly.  Besides, am I really going to run 200+ instances of
 Apache?  That seems unreasonable.

Run php using fastcgi/suexec (every user will have his own PHP running
using his uid).
That's how textdrive/joyent do this and they are more than happy with
this approach.

-- 
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Mark Krenz
On Mon, Nov 05, 2007 at 05:28:07PM GMT, Cristian Rodriguez [EMAIL PROTECTED] 
said the following:
 
 safe_mode does not really resist any analysis, whoever convinced you
 that it is a good thing does not have a clue.
 

  I've done the analysis, so you're saying that I don't have a clue.  I
don't think that's the case, its more that I have a alternate way of
looking at security than you.  I feel like I'm up against a religion.  A
lot of people who counter me probably haven't done any security analysis
of safe mode themselves, they are just repeating what they have heard.
And they are virulently opposed to what I suggest because they heard the
term safe mode and it short circuits their brain.

  And regarding the OS thing.  What could I really sanely do to prevent
this at the OS level?  How can I make it so that Apache and its modules
are only able to execute a specified set to programs?  Chroot is not the
answer to this either.  Either Apache has to be redesigned or PHP has to
be redesigned.  Since Apache has a much broader scope than PHP does, I'd
say that responsibility falls onto PHP.

  I get the feeling that a lot of people who give support for PHP both
through mailing lists, books, IRC, etc. have never had to run a shared
user server.  Everytime I have discussions about things like this I
encounter people who have crackpot ideas that simply wouldn't work in a
shared environment or would be cost prohibitive.  These solutions may
work fine at home, but not on a server with 100+ unrelated users.

  Security solutions should be simple and obvious.  Complex ones
discourage people from implementing them.  Given that most of the web
hosting industry just used cpanel or plesk installations and doesn't
give a thought to the security that they offer for things like PHP,
you're counting on those systems to use a setup that is secure. Since
those web control panels are written by programmers wanting to automate
everything, chances are that not much thought has been given to a secure
design of operation. I could be wrong, but that's usually the case.

  The PHP team has a responsibility to not just drop safe mode right
away without any period of advisement to the community.  There needs to
be a transition period in which sane solutions are presented to the
community.  Right now I don't see any of that going on.  PHP is just
saying Hey, we're dropping safe mode, deal with it.  That is
irresponsible.  I'm not saying keep safe mode in PHP, I'm saying have a
good plan for everybody and provide them with transition tools (like a
setting for preventing execution outside of a set directory) if you are
going to remove it.

 Mark

-- 
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Michael McGlothlin
Much easier and better to just throw every user their own virtual 
machine. They can go wild and you don't have to worry. Makes it easy to 
control how much CPU, RAM, and hdd the user is using too.


--
Michael McGlothlin
Southwest Plumbing Supply

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Mark Krenz
On Mon, Nov 05, 2007 at 06:35:50PM GMT, Alexey Zakhlestin [EMAIL PROTECTED] 
said the following:

 That's how textdrive/joyent do this and they are more than happy with
 this approach.
 

 Oh really?  Read the section on Joyent/Textdrive here:

  http://suso.suso.org/xulu/Web_hosting_providers_with_poor_security

 Now do you have confidence in their security practices?

 Suso is secure with the exception of some of the more obscure flaws in
safe mode. You can't read other people's files.   I try not to don't
rely on security by obscurity.  I want to be able to sleep at night.


-- 
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Mark Krenz

  That's obvious and I do offer that.  But what about users in a shared
environment?  There has to be a way to have cheaper accounts for people
and the way to do that is to put a couple hundred of them on a machine.

On Mon, Nov 05, 2007 at 06:42:35PM GMT, Michael McGlothlin [EMAIL PROTECTED] 
said the following:
 Much easier and better to just throw every user their own virtual 
 machine. They can go wild and you don't have to worry. Makes it easy to 
 control how much CPU, RAM, and hdd the user is using too.
 
 --
 Michael McGlothlin
 Southwest Plumbing Supply
 


-- 
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Michael McGlothlin



  That's obvious and I do offer that.  But what about users in a shared
environment?  There has to be a way to have cheaper accounts for people
and the way to do that is to put a couple hundred of them on a machine.
  
It'd be pretty easy to run a copy of Apache for each user on their own 
port with a proxy in front to direct things but again it'd probably be 
more resource intensive than safe mode. Shared environments suck anyway 
though. You can get a pretty decent dedicated machine for $50/mo and a 
virtual machine for $20/mo. People who only want to pay $5/mo should 
expect things to suck so just make them stick to PHP5.


--
Michael McGlothlin
http://www.PlumbersStock.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Alexey Zakhlestin
Did you just ignore the part about fastcgi?

On 11/5/07, Mark Krenz [EMAIL PROTECTED] wrote:
 On Mon, Nov 05, 2007 at 06:35:50PM GMT, Alexey Zakhlestin [EMAIL PROTECTED] 
 said the following:
 
  That's how textdrive/joyent do this and they are more than happy with
  this approach.
 

  Oh really?  Read the section on Joyent/Textdrive here:

   http://suso.suso.org/xulu/Web_hosting_providers_with_poor_security

  Now do you have confidence in their security practices?

  Suso is secure with the exception of some of the more obscure flaws in
 safe mode. You can't read other people's files.   I try not to don't
 rely on security by obscurity.  I want to be able to sleep at night.


 --
 Mark S. Krenz
 IT Director
 Suso Technology Services, Inc.
 http://suso.org/

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Mark Krenz
On Mon, Nov 05, 2007 at 07:02:05PM GMT, Alexey Zakhlestin [EMAIL PROTECTED] 
said the following:
 Did you just ignore the part about fastcgi?


  No I didn't, I just feel that fastcgi/suexec/mod_suphp doesn't handle
all of the ready to run programs out there completely. Besides that, the
whole point of PHP was that it was made to be part of Apache originally,
so why not just have us all write Perl scripts?

  See, my problems with PHP setups come down to this:

   A. I could run PHP without safe mode and only have open base dir on
  and be wide open for breaches.

   B. I could run mod_suphp/suexec/fastcgi for everyone and then certain
  programs would not run right. Performance would take a bit of a
  hit.  People would say Why are you running it like that, you're dumb,
  etc.  My impression of this scenario is based on a few years old
  information, testing and perhaps not enough research so maybe I should
  look into this method again.

   C. I could use the metux MPM, but then I couldn't do SSL, which means
  no ecommerce sites.

   D. I could run things the way I have it now, but that won't last
  because PHP 6 is on the way.

   E. I could run Apache chroot and have 50 instances of Apache running
  on a server.  Performance would no doubt take a hit, even with
  lots of CPUs and RAM.  I have also planned for about 200 users per
  server so I'd be losing a lot that way.  Complexity would go way up as
  well as management time and I'd have to deal with users messing up their
  chroot environments.

   F. Try to get the mpm-itx setup working, but that's an unknown right
  now.

  I should have taken that sign more to heart that I read one time:
Formula for failure: Try to please everybody.

  Mark

 

-- 
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Nate Gordon

Unless there is some other way in PHP of restricting where you can run
  programs from (can't find any),

 Why PHP needs to do that ? isnt that part of OS level security ?

There are those of us in shared environments where scripts can't be
run as a single user because the content is owned by a group of users
and thus a group is the limiting factor.  Since PHP is what is
allowing me to run scripts/progs through a php function I don't see
how it would be that difficult to lock that down to a specific
directory on a per vhost basis.


 this is going to become a major problem.

 This is going to **solve** a major problem, this change will eliminate
 the false sense of security that safe_mode provides and will tell
 people to start securing their stuff better.

 safe_mode does not really resist any analysis, whoever convinced you
 that it is a good thing does not have a clue.

I will be the first to acknowledge that the basic premise of safe_mode
is broken (the part about uids/gids matching), but the extra feature I
used was a per vhost disabling of executing anything that wasn't php.

This is the real feature I want, simple per vhost disable functions.
I realize that suhosin provides a per vhost disable functions feature,
but why is it up to an extension to provide that?  The next thing I
would want is a per vhost exec dir limit.

People are too quick to throw out the baby with the bath water on
safe_mode.  It isn't completely useless to everyone.


-- 
-Nathan Gordon

If the database server goes down and there is no code to hear it, does
it really go down?
esc:wqCR

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-11-05 Thread Mark Krenz

  Yes, this is what I'm talking about.  Now is the time to do this
before some distribution of Linux or whatnot includes a version of PHP 6
that would not have this feature.

  I'm sorry I can't code very well in C.  But I'd be willing to write
documentation or a migration guide or something.  Just let me know how I
can help.

  Mark

On Tue, Nov 06, 2007 at 03:13:36AM GMT, Peter Brodersen [EMAIL PROTECTED] said 
the following:
 
 It has earlier been stated that it would be a fine idea to unbundle
 safe_mode_exec_dir from safe_mode:
 
 http://news.php.net/php.internals/20417
 
 I suppose that now is later :)
 
 
 Basically it comes down to serve as a central switch for exec like
 functions instead of maintaining an ever-changing list of functions
 under disable_functions which would make upgrades cumbersome.
 
 -- 
 - Peter Brodersen
 


-- 
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-09-02 Thread Peter Brodersen
On Sun, 26 Aug 2007 22:59:16 -0700, in php.internals
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:

 As PHP grew
and became more complex and linked in more complex libraries, it became
completely impossible to even begin to pretend that safemode was still
effective. 

1½ year ago we talked about unbundling the safe_mode_exec_dir and
keeping that alive:
http://news.php.net/php.internals/20417

Is this still relevant? I like the idea much more than users should
maintain their own disabled_functions list to prevent current and new
exec functions.

-- 
- Peter Brodersen

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-08-27 Thread Rasmus Lerdorf
Mark Krenz wrote:
   ???  What do you mean?  I talked with Ryan Bloom about this at Apache
 Con 2000 and he said that with Apache 2.0, modules would be able to run
 code with the permissions of the user assigned to each vhost.  I asked
 about the prospect of PHP being able to utilize this and he said its
 possible, but I got the impression that the PHP devs where not
 interested.

This is the perchild MPM.  It was supposed to allow you to configure a
given number of threads per user, which in your case would mean per
virtualhost, and it would route requests correctly to these pools of
threads.  If you had done a bit of reading on the history of the
perchild MPM since 2000, you would have discovered that it was never
completed and it is no longer part of Apache2.  The concept looked sort
of ok on paper, but it had a number of problems.  On the PHP side the
main drawback with it was that it required a threadsafe environment.
Back in 2000 most of the libraries PHP could be linked against were not
threadsafe, and even today it is rather risky to run in threaded mode if
you link in a lot of 3rd-party libraries.  A small dedicated server with
a limited number of extensions can run quite well threaded, but in an
ISP situation where you basically have to link in everything under the
sun, getting everything stable and robust in a threaded environment is
painful.

You will never get a 100% secure web server.  It just doesn't happen.
The best you can do is use a layered approach where each of your layers
act at different levels and hope that the holes in each of your layers
don't all line up.  Think of it as using 3 innertubes in a tire each of
them with a couple of holes in them.  You'd have to be pretty unlucky to
have a leaky tire.  But in order for this to work the layers have to act
on different levels and they have to all be trying to achieve one thing.

In our case, what we are trying to achieve is to prevent external users
from exploiting flaws in PHP or in userspace code to attack the server
or the application.  Safemode doesn't fit this.  Safemode was a
misguided attempt at providing some sort of protection against malicious
users on the same server.  There are no layers to help us here, and it
has multiple known holes, so the tire is always flat.

PHP is the wrong level to try to protect users from other users on the
same server.  No language does this.  You brought up Perl, for some
reason.  It also has absolutely no way to protect two perl scripts that
run as the same user id on the same server from mucking with each
others' files.  I added safemode to PHP years and years ago when it was
a much simpler beast.  I'm not (always) an idiot, and I knew at the time
that it wasn't the right place to add this protection, but the
alternatives at the time weren't viable, and I needed it.  It was even
somewhat effective since it has less things to deal with.  As PHP grew
and became more complex and linked in more complex libraries, it became
completely impossible to even begin to pretend that safemode was still
effective.  Any 3rd-party library that accesses files are not subject to
the safemode check unless we can somehow catch it at the PHP level.  For
stuff like the Oracle client library where an sql query can open a file,
and that query can be written a hundred different ways, there is
absolutely no way to make safemode work.  We don't have the source code
to this library and there are no hooks for us to override file access in
it.  I appreciate that you think we should just solve these problems and
make safemode perfect because that would make your life easier, and I
appreciate, well I don't actually, that you think we are idiots for not
doing so, but while we may be idiots, we have actually thought about
this quite a bit, and we consider it an intractable problem.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-08-27 Thread Cristian Rodriguez
On 8/26/07, Mark Krenz [EMAIL PROTECTED] wrote:

   No, this is the wrong way to approach the problem.

No, this is the right way, language level security does not replace OS
level security.

 I'm bringing it up because its something that
 needs to be fixed in PHP.

No, fixing this issue in PHP itself is the wrong way, the only issues
that needs to be fixed in PHP are.

1. security holes of PHP itself.

2. the PHP documentation in the cases it promotes bad programming practises.

3. disabling include() and require() with URls **permantently** may
help as well ;P


   But I'm one of the ones from the 90s that cares greatly about
 security.

If you care greatly about security then safe_mode is certainly **not**
what you need, if you think so, you have been seriously misguided.


-- 
http://www.kissofjudas.net/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Safe mode being removed in PHP6?

2007-08-26 Thread Mark Krenz

  First of all I don't want this to sound like a personal attack, its
professional.  I just encountered something that really aggrevates me
about the state of PHP and I want to be heard by the developers.

 I just read through this document,

   http://www.php.net/~derick/meeting-notes.html

 and read the notes on safe_mode and open_basedir. PHP as is, is a real
pain in the ass to lock down completely and it always has been. In fact,
I'd venture to say that its impossible.  And believe me when I say that
I've tried and I'm no slouch.  The only way I can really lock it down is
to use modules like mod_suphp that run the scripts simular to how suexec
works.  But I can't just turn that on for every user on my system
because things like Mediawiki simple URLs don't work right and possibly
other things won't work.  Some developers will not take responsibility
for their programs not working and I'm getting tired of telling my
customers that there are brain dead developers out there writing popular
software.

 The PHP developers trying to shun the problems off to being an Apache
problem or OS problem is irresponsible. If PHP is a module running in
Apache.  What can Apache do?  Maybe I'm missing something here.

  open_basedir is vulnerable to the work around and safe_mode is
vulnerable to other problems that I've notified the developers about.
But removing safe_mode will only make things more unsecure not less.  I
know its a pain in the ass for people, but I think that until the PHP
developers can come up with a 100% secure way to run PHP, they shouldn't
be removing functionality like this.  Otherwise I'm going to have to
stay away from PHP 6.  My security model for websites on Suso is
partially based around safe_mode and other things like suexec and
enforcing restrictive permissions on user's homedirectories and so on.
But take safe mode away and users will be able to execute programs that
can read other user's files.  As simple as writing a program like this:

$arg = /home/otheruser/www/filewithdbpassword.inc;

$output = ;
exec(/bin/cat $arg, $output);

print $output[0];

  Its pretty trivial to get around the security of open_basedir alone,
and I can't think of a way to prevent this using Apache or filesystem
permissions.  Perhaps there is a way using ACLs or selinux, but of
course this wouldn't work on all systems and I think that is expecting
too much.

  So what is the plan for increasing the security of PHP rather than
decreasing it?  I've been waiting since Apache 2.0 (7 years now) for PHP
to take advantage of things Apache 2.0 offers in terms of being able to
let modules run as the user, but I've seen nothing in this regard.

-- 
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-08-26 Thread Stanislav Malyshev

 and read the notes on safe_mode and open_basedir. PHP as is, is a real
pain in the ass to lock down completely and it always has been. In fact,
I'd venture to say that its impossible.  And believe me when I say that


No more and no less than any other scripting language, I'd say. And the 
reason for that - it should be done on the OS level, not on the language 
level. OS possesses the capability and created with exactly this purpose.



I've tried and I'm no slouch.  The only way I can really lock it down is
to use modules like mod_suphp that run the scripts simular to how suexec


I'd attempt some solution involving FastCGI. I think pretty urls 
should still work with that, though this needs some checking.



 The PHP developers trying to shun the problems off to being an Apache
problem or OS problem is irresponsible. If PHP is a module running in
Apache.  What can Apache do?  Maybe I'm missing something here.


Apache can't do much. OS should do it. Now, how to make OS do it there 
you can have a number of solutions, starting with different user IDs and 
up to using things like AppArmor and SELinux.



But removing safe_mode will only make things more unsecure not less.  I


Removing safe_mode is recognition of un-feasibility of solving this 
problem in PHP context. PHP uses dozens of external libraries, which are 
very hard to control on the level of PHP. Because of that, PHP is not on 
the level which is necessary to provide user-based security - it's too 
high-level.



developers can come up with a 100% secure way to run PHP, they shouldn't
be removing functionality like this.  Otherwise I'm going to have to


Having security solution that works in 90% of the code is no better than 
not having any. Actually, it's worse since some people may mistakenly 
rely on that 90% as if it were 100% and thus neglect to look at the real 
security solutions, leaving the system as vulnerable as if they had no 
security at all.



decreasing it?  I've been waiting since Apache 2.0 (7 years now) for PHP
to take advantage of things Apache 2.0 offers in terms of being able to
let modules run as the user, but I've seen nothing in this regard.


Unfortunately, Apache never really supported running multipe-user 
servers on single Apache instance.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-08-26 Thread Richard Lynch
On Sun, August 26, 2007 2:31 pm, Mark Krenz wrote:
   First of all I don't want this to sound like a personal attack, its
 professional.  I just encountered something that really aggrevates me
 about the state of PHP and I want to be heard by the developers.

First make sure you understand what safe_mode does, and doesn't do,
and just how lame it is at what it tried to do, and fails to do, and
simply cannot do.

Next, understand that it generates a zillion support problems for you,
webhosts, PHP-General, and Internals/Bugs/QA, from people who see
safe_mode and say Oh!  I want that.  It's safe! -- who are
100% wrong, because they haven't a clue what it actually does and how
it works, and then they complain when it does exactly what it was
designed to do.

Any developer in any Apache Module can open up giant gaping holes,
and, obviously, many of them do, even in popular PHP web apps.  I
daresay particularly in popular PHP web apps, since PHP is so dead
easy to get started with and write something nominally useful in a
matter of hours of study rather than months.

I sincerely doubt that safe_mode has saved anything at all for you
in a long, long, long time however.

Perhaps there are several courses of action you could consider long-term:

1) Expand your use of suphp as much as practical

2) Ban webapps you know to be fundamentally insecure; those with a
long history of serious vulnerabilities

3) Actively seek out and push users to upgrade webapps with known
vulnerabilities.  (It shouldn't be that hard to write a grep/find that
seeks out PhooBah 1.0.0 in any file named 'badforum/config.inc' and
run that in a cron every day for yourself)

 works.  But I can't just turn that on for every user on my system
 because things like Mediawiki simple URLs don't work right and
 possibly
 other things won't work.

[flummoxed topic=off]
How does MediaWiki manage to screw up simple URLs pages on suphp?...
[/flummoxed]

 Some developers will not take responsibility
 for their programs not working and I'm getting tired of telling my
 customers that there are brain dead developers out there writing
 popular
 software.

I understand and sympathise with you.

Perhaps a published list of banned software that you can direct
users to would be a useful addition to your control panel or FAQ or
even your terms of service agreement.

If you tell your prospective users up-front that PhooBah 1.0.0 is
BANNED due to serious security vulnerabilities, some, not all, but
some, of your woes go away.

  The PHP developers trying to shun the problems off to being an Apache
 problem or OS problem is irresponsible. If PHP is a module running in
 Apache.  What can Apache do?  Maybe I'm missing something here.

Apache could provide the sudo on a VirtualHost or even Directory
basis, for example...

At least, that's what *I* would imagine could be done.

 open_basedir is vulnerable to the work around and safe_mode is
 vulnerable to other problems that I've notified the developers about.
 But removing safe_mode will only make things more unsecure not less.

I seriously doubt that removing safe_mode will actually make anything
less secure for your server.

It is a false security blanket doing little of any real-world use.

 I
 know its a pain in the ass for people, but I think that until the PHP
 developers can come up with a 100% secure way to run PHP, they
 shouldn't
 be removing functionality like this.

I'm sure that when you re-read the above paragraph, you'll realize
just how silly it is...  I'll stop here. :-) :-) :-)

 Otherwise I'm going to have to
 stay away from PHP 6.  My security model for websites on Suso is
 partially based around safe_mode and other things like suexec and
 enforcing restrictive permissions on user's homedirectories and so on.
 But take safe mode away and users will be able to execute programs
 that
 can read other user's files.  As simple as writing a program like
 this:

 $arg = /home/otheruser/www/filewithdbpassword.inc;

 $output = ;
 exec(/bin/cat $arg, $output);

 print $output[0];

Yeah, but with safe_mode on, all I have to do is create a symlink and
if Apache is set up to follow symlinks, I can read that anyway.  I've
done that just to recover my own db password rather than bothering my
webhost support staff with a request and waiting  24 hours. (They
usually answer something that simple in  1 hour, actually...)
PS I did it behind an .htaccess file and nuked it as soon as I had the
password, of course.  I'm not a TOTAL idiot... :-)

For that matter, on every shared host I've ever used, guessing
somebody else's db password and cracking it with a brute-force attack
based on *my* database password seems like it would be pretty trivial.

I've had hosts where it was always db#, so I had to do, what,
1 million db connections until I got it right?  Spread that million db
connections out over a few weeks and call it done, no?

Another host was clearly taking 2 short words (short = one or two
syllables) from 

Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-08-26 Thread Nate Gordon
On 8/26/07, Richard Lynch [EMAIL PROTECTED] wrote:

 First make sure you understand what safe_mode does, and doesn't do,
 and just how lame it is at what it tried to do, and fails to do, and
 simply cannot do.

I am all for the removal of safe mode in php.  I use safe_mode now,
but I patch it to effectively only do function disabling.  My hosting
setup is mixed between code I write, and code I host.  So some of my
virtual hosts are given full run of the server, while other hosts are
limited to their little box.  The disable_functions ini_setting would
be able to accomplish this task perfectly, except that it is not per
virtual host.  If that was changed all my needs would be covered.

I would look to more OS type solutions, but unfortunately I run
everything off of AFS (read as non-standard unix fs with weird issues
in becoming a different user per vhost).

-- 
-Nathan Gordon

If the database server goes down and there is no code to hear it, does
it really go down?
esc:wqCR

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-08-26 Thread Cristian Rodriguez
On 8/26/07, Mark Krenz [EMAIL PROTECTED] wrote:

   So what is the plan for increasing the security of PHP rather than
 decreasing it?

The plan is probably increasing the security of PHP, and removing
safe_mode is an step to do that, false sense of security is worst than
no security at all, unfortunately there are lot of people that
believes in the myth that safe_mode actually provides security...

safe_mode is one of the worst, ill-concieved features of PHP and Im
glad to see last of it.

No, it does not work the way you expect, Ilia has an interesting
article about this see

http://ilia.ws/archives/18-PHPs-safe_mode-or-how-not-to-implement-security.html







-- 
http://www.kissofjudas.net/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-08-26 Thread Mark Krenz
On Sun, Aug 26, 2007 at 09:15:54PM GMT, Stanislav Malyshev [EMAIL PROTECTED] 
said the following:
 No more and no less than any other scripting language, I'd say. And the 
 reason for that - it should be done on the OS level, not on the language 
 level. OS possesses the capability and created with exactly this purpose.

  Really?  Take anything that runs through CGI.  I can turn on suexec
for it and it will function the same plus it will run as the user and
that gives me more benefits.  But the architecture of how it runs is
100% secure, putting aside any vulnerabilities in the code that come up.

 Apache can't do much. OS should do it. Now, how to make OS do it there 
 you can have a number of solutions, starting with different user IDs and 
 up to using things like AppArmor and SELinux.

  No, this is the wrong way to approach the problem.  With hundreds of
users, all doing different things, there is a strong possibility that
I'll have to maintain such SELinux or apparmor rules for each user's
website.  That's rediculous.  A secure server should be something that
is easy to accomplish, not difficult, lest you will have a situation
where the majority of sysadmins would rather just leave it insecure than
figure out the complexities of something like selinux.  I'm not just
bringing this up for me, I'm bringing it up because its something that
needs to be fixed in PHP.  I didn't fight this fight before because
I figured, there are a lot smarter people out there closer to the PHP
team that would bring these issues up.  But appearently not.  I can't
believe this is still an issue as of PHP 6.  I started using PHP at
version 2.

 Removing safe_mode is recognition of un-feasibility of solving this 
 problem in PHP context. PHP uses dozens of external libraries, which are 
 very hard to control on the level of PHP. Because of that, PHP is not on 
 the level which is necessary to provide user-based security - it's too 
 high-level.

  No more high-level than Perl.  What's the difference?  The real
problem stems from PHP being TOO configurable.  This led to people
turning things on and off over the years and thinking certain things
were good and bad.  I think its generally a bad idea to make a
programming language configurable.  PHP takes it to an extreme.  So you
wind up with people saying Just do this and you'll be fine and others
getting into religious wars over whether things like magic quotes are
good or bad.

  A programming language should not be configurable, it should be
standardized so that people can be sure that programs run consistently
for all people that run them.

 Having security solution that works in 90% of the code is no better than 
 not having any. Actually, it's worse since some people may mistakenly 
 rely on that 90% as if it were 100% and thus neglect to look at the real 
 security solutions, leaving the system as vulnerable as if they had no 
 security at all.

 Well that's what we seem to have.  Its more like 50% acting like 100%.
This is off topic but I recently did a security investigation of
Dreamhost and their security practices where rediculous.  And they say
on their website that they are protected by ninjas.  Obviously there
are a lot of web hosting companies out there that don't care.

  But I'm one of the ones from the 90s that cares greatly about
security.  I know there are hackers knocking on the door all the time
and some of them can overcome trivial vulerabilities. Beyond that,
users should never be able to read other user's data. Heck, while
writing this a user wrote me about their wordpress site being hacked.
Now that may have been a Wordpress known vulnerability, but it doesn't
matter, without safe_mode on, it could have been worse.

 decreasing it?  I've been waiting since Apache 2.0 (7 years now) for PHP
 to take advantage of things Apache 2.0 offers in terms of being able to
 let modules run as the user, but I've seen nothing in this regard.
 
 Unfortunately, Apache never really supported running multipe-user 
 servers on single Apache instance.

  ???  What do you mean?  I talked with Ryan Bloom about this at Apache
Con 2000 and he said that with Apache 2.0, modules would be able to run
code with the permissions of the user assigned to each vhost.  I asked
about the prospect of PHP being able to utilize this and he said its
possible, but I got the impression that the PHP devs where not
interested.

-- 
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Safe mode being removed in PHP6?

2007-08-26 Thread Stanislav Malyshev

  Really?  Take anything that runs through CGI.  I can turn on suexec
for it and it will function the same plus it will run as the user and
that gives me more benefits.  But the architecture of how it runs is
100% secure, putting aside any vulnerabilities in the code that come up.


It's what I call OS approach, since it bases itself on user ID for 
security, and on OS to check user ID. So, what prevents you from running 
PHP as CGI/suexec without safe mode?



  No, this is the wrong way to approach the problem.  With hundreds of
users, all doing different things, there is a strong possibility that
I'll have to maintain such SELinux or apparmor rules for each user's
website.  That's rediculous.  A secure server should be something that


Sorry if there's no adequate solution for your particular case on the 
market. But that doesn't mean PHP should try to become AppArmor or SELinux.



  No more high-level than Perl.  What's the difference?  The real


The difference is, last that I heard Perl has no safe mode. perl has 
taint mode which is very different and maybe - if somebody succeeds in 
doing that - can be done in PHP too.



writing this a user wrote me about their wordpress site being hacked.
Now that may have been a Wordpress known vulnerability, but it doesn't
matter, without safe_mode on, it could have been worse.


Since safe mode never really provided secure environment, I don't see 
how it would be worse.



  ???  What do you mean?  I talked with Ryan Bloom about this at Apache
Con 2000 and he said that with Apache 2.0, modules would be able to run


There's a difference between would be able to and works. For now, 
Apache docs say:

http://httpd.apache.org/docs/2.2/mod/mpm_common.html#user
The User directive sets the user ID as which the server will answer requests
/.../
Special note: Use of this directive in VirtualHost is no longer 
supported. To configure your server for suexec use SuexecUserGroup.


perchild MPM in 2.0 docs says:

This module is not functional. Development of this module is not 
complete and is not currently active. Do not use perchild unless you are 
a programmer willing to help fix it.



code with the permissions of the user assigned to each vhost.  I asked
about the prospect of PHP being able to utilize this and he said its
possible, but I got the impression that the PHP devs where not
interested.


We would be very interested to see Apache implementing this capability, 
but as I understand it never worked stable in 2.0 and was removed in 2.2.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php