Drush prefilght checks too restrictive

drush 4.x refuses to run if disable_functions is not empty. It seems too restrictive to refuse running if any function is disabled, specially 'dl'.

OTOH it seems you're not getting the newly generated php.ini in the second run. Perhaps 'dl' is forced to be disabled always.

I agree that current check is too restrictive. we should blacklist a couple key commands or leave the checking to the command's validate hook.

With this patch, drush will only complain about disable_functions if it includes 'exec' or 'system'. Also, it seemed much too restrictive to prevent the user from running 'help' or 'status' when their php.ini settings were not right, so I changed it from a set error to a log 'error', and allow execution to continue. (Hopefully the user will read the first error message and figure out what to do if a complex command fails due to a bad .ini value.)

missing patch but I like the change.

Here is the patch.

+	  $invalid_value = TRUE;

+	}

other than you're using tabs in above lines it looks fine.

Powered by Dreditor.

Committed (w/out the tabs...)

Hi,
I see this was marked as fixed. I'm using the recommended version of drush 4.2 (downloaded 2/17/11) and am getting the same error. When do fixes end up in the releases? Sorry if this is an obvious question, I'm still learning the ropes around here.
Thanks,
Ember

By "same error" do you mean: "The following restricted PHP modes have non-empty values: disable_functions."? Take a look at README.txt and examples/example.drush.ini, and give yourself a less restrictive php.ini for drush. Could be that your ISP does not support php-cli, in which case you will have problems with drush.

Hi Greg,

Thanks for replying. Here's the error when I run drush status:

The following restricted PHP modes have non-empty values:            [error]
disable_functions. This configuration is incompatible with drush.
Please check your configuration settings in /etc/drush/php.ini or in
your drush.ini file; see examples/example.drush.ini for details.
 PHP configuration     :  /etc/drush/php.ini
 Drush version         :  4.2
 Drush configuration   :
 Drush alias files     :

It's our own server. I am trying to lock down things as much as possible. I removed exec and system from the list of disabled functions. Is there something else that needs to be removed? Based on the error I received, I thought it was still the same error initially reported and the fix just hadn't moved in to this version of drush.

Thanks,
Ember

You should put whatever you want in disable_functions for your web server, but leave disable_functions empty for php-cli. Since you already have your drush php.ini file in /etc/drush/php.ini, empty out disable_functions there. That will not affect your webserver configuration, so you do not need to worry about security. People who are using drush from the shell can already exec from the shell.

Hey Greg. Maybe I'm being pedantic here, but we typically run from the privilege of least access. Blanket removal of disable_functions doesn't seem like a great idea to me. Aren't some users running Drush on a shared host? It may not be in their web-executable folder, but considering the general vulnerabilities in that kind of environment, the least privileges available, the better.

We typically turn off show_source, popen, passthru, and curl_multi_exec. Does Drush really need these?

@crimsondryad: All of your points are valid for the web server's cli, but if you allow your users to run drush (which uses the cli php.ini), there is no point in turning off popen (which drush needs). If you are afraid that a drush user might 'trick' drush into using popen to run an arbitrary program, then you should also be afraid that they might run that same program directly from the bash shell. To close this security hole, the best thing to do is to change the /etc/passwd entry for untrusted users from :/bin/bash to :/bin/false. This will guarantee that they cannot use drush to run arbitrary programs.

Running drush with a non-empty disable_functions might work for some values of disable_functions, but this is not a supported configuration, nor is it "more secure".

Well, those kinds of concerns are exactly the reason why paranoid corporate types (like me) will not let our devs use Drush - which is sort of sad because Drush is a great tool. We are also thinking about all the kinds of things devs can use with a ssh login. The fact is, our devs will not have sudo access on the machines. Because Drush runs with escalated privs, the likelihood that they will be able to do something (like trick Drush ) is higher. Of course there comes a point where you have to trust your users not to do something stupid and / or nefarious. But we also allow some vendors onto our staging environment and we don't want them running amok. I do know about the policy.php file, I need to research exactly what I can restrict with it.

Some paranoid corporate types won't take the time to research and just won't offer Drush access at all.

I understand where you're coming from...security should be about tangible benefits and not just checking off some box on a list. Unfortunately that is exactly what some of us are required to do. If (when) a breach happens, business units will want details about exactly how we set up our machines. And when we tell them disable_functions was entirely removed for stuff that wasn't strictly needed and we tell them "because Greggles told us so" that isn't going to count as a legitimate reason, regardless of how much we respect your option ( and make no mistake, I do ).

Just sayin' :)

Sorry, greggles is a different drupal.org user with a much higher reputation then I command. But to your point, yes, I agree with you; you should remove shell access and drush from systems that have that high of a security profile.

Did you know that you can use drush on your dev system, and still push from dev to production even if you don't have drush or php-cli on your production server? You don't have to offer drush on production at all.

Oh, this *is* dev. We don't even allow devs or vendors to have ANY access to our production machines except for the media storage. Though we do have drush installed on our production machines, it uses a custom .ini and my group has the only access. My point is that the NSA server hardening guidelines require certain functions to be disabled. We are *required* to follow it unless we can show a compelling reason not to.

Also, many exploits are based on chaining together multiple vulnerabilities. In and of itself it may not be a big deal. String it with other stuff and sudden there are larger problems. Anything that results in the attacker getting one bit of extra data is worth protecting against. For instance...Epilson. Email addresses got hacked and that was bad enough. But what if the breach could've been a lot worse? Least access is your friend. :)

Sorry about the mistaken identity, the days (and my eyes) are starting to blur together. :) I saw a "g" on a security topic and my head filled in "greggles". No offense meant.

Okay, I get that your security requirements are really high, but I'm not sure whether or not you understand that (a) php-cli has a different php.ini than your webserver php.ini, and (b) you need shell access to use drush, and there is no php function worth blocking in disable_functions that you cannot duplicate by doing an equivalent operation with bash (or whatever shell you're using).

I think that you can show that you are following your server hardening guidelines for your webserver php.ini; if the php-cli php.ini is only relevant to people with shell access, and people with shell access already have an equal or greater ability to affect the system directly (than php-cli / drush allows), then I would say that is a compelling enough reason to not further harden the php-cli php.ini.

If you have somehow blocked shell access, but are allowing users to access drush by some other means, then and only then would I think that it was worthwhile to start hardening drush to the level that you are proposing. Of course, if that really is where your needs lie, you have to realize that your requirements are way higher than the other drush maintainers' are, and the odds of getting someone to do this quite substantial amount of work for you is rather low -- realizing, of course, that simply supporting a non-empty disable_functions in drush being entirely insufficient for this level of security.

Greg makes a solid technical argument. I've not seen a coherent technical argument for the other side.

I'll just add a personal note that I develop and maintain drush because it is fun for me and others seem to enjoy it too. Adding/Removing features for the sole purpose of satisfying DoD or NSA checkbox is a no-go here. Fact based arguments win, not rote compliance.

I just wandered onto this thread and I suspect others will too. I saw a lot of discussion of using PHP CLI but no explanation of how to do it. For anyone else who was as confused as me, this is what you need to put in .bash-profile (or .bashrc):

alias drush='php /home/<username>/public_html/drush/drush.php'
alias php='/usr/bin/php-cli'