Re: [PHP-DEV] Safe mode being removed in PHP6?
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?
On Mon, 5 Nov 2007 17:12:03 +, in php.internals [EMAIL PROTECTED] (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 -- 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?
> > > 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? :wq -- 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?
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?
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?
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?
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?
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?
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?
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?
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/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?
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: 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. It just doesn't happen. > The best you can do
Re: [PHP-DEV] Safe mode being removed in PHP6?
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?
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
Re: [PHP-DEV] Safe mode being removed in PHP6?
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?
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 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
Re: [PHP-DEV] Safe mode being removed in PHP6?
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?
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?
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? :wq -- 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?
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 clearl
Re: [PHP-DEV] Safe mode being removed in PHP6?
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
[PHP-DEV] Safe mode being removed in PHP6?
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
