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/
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
On Sun, Aug 26, 2007 at 09:15:54PM GMT, Stanislav Malyshev [stas@zend.com] 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/
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
On Sun, 26 Aug 2007 22:59:16 -0700, in php.internals
rasmus@lerdorf.com (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
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 [rasmus@lerdorf.com] 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. 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
--
--
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/
2007/11/5, Mark Krenz mark@suso.org:
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.
On Mon, Nov 05, 2007 at 05:28:07PM GMT, Cristian Rodriguez [judas.iscariote@gmail.com] 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/
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
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 [michaelm@swplumb.com] 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/
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/
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>:wq<CR
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/
On Mon, Nov 05, 2007 at 06:35:50PM GMT, Alexey Zakhlestin [indeyets@gmail.com] 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/
Did you just ignore the part about fastcgi?
On Mon, Nov 05, 2007 at 06:35:50PM GMT, Alexey Zakhlestin [indeyets@gmail.com] 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/--
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
On Mon, Nov 05, 2007 at 07:02:05PM GMT, Alexey Zakhlestin [indeyets@gmail.com] 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/
On Mon, 5 Nov 2007 17:12:03 +0000, in php.internals mark@suso.org
(Mark Krenz) wrote:
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.
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
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 [penguin@php.net] 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/
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.
-
security holes of PHP itself.
-
the PHP documentation in the cases it promotes bad programming practises.
-
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.
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 "Oooooh! 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:
-
Expand your use of suphp as much as practical
-
Ban webapps you know to be fundamentally insecure; those with a
long history of serious vulnerabilities -
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 the dictionary, whose leading letters matched
something in the domain name or username. And, actually, they were
generally using something kind of funny/punny based in the names, it
seemed, though perhaps that was my twisted take on a too-small sample.
Still, how many words start with any given letter in /etc/shared/web2
or whatever it is? Well within the grasp of a week's worth on
indetectable cracking, I would imagine.
I've never TRIED this
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.
I would hope that PHP would have nothing in the way of that working as
designed by Apache 2.x It would be up to you to configure in
httpd.conf, as I understand it, no?
I'm not 100% clear on how Apache 2.0 does this, or even what Apache
2.0 offers in this regard, though, so perhaps I'm missing the boat on
this one.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
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>:wq<CR
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