Security issue with ruby gems install.

[4u123]

Got a customer having problem trying to install the MySQL Gem.

'ERROR: Failed to build gem native extension...
Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers.'

looked in the log - recurring error is...

sh: /usr/bin/gcc: Permission denied

I guess this is happening because ive used the "compilers tweak" in WHM to disable access to compilers for users - but it seems in order to install these gems, the user must have access to gcc - which is a security issue in my opinion.

Is there no way of making this work without changing the permissions on this file ?

[cPanelDavidG]

Got a customer having problem trying to install the MySQL Gem.

'ERROR: Failed to build gem native extension...
Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers.'

looked in the log - recurring error is...

sh: /usr/bin/gcc: Permission denied

I guess this is happening because ive used the "compilers tweak" in WHM to disable access to compilers for users - but it seems in order to install these gems, the user must have access to gcc - which is a security issue in my opinion.

Is there no way of making this work without changing the permissions on this file ?

For users to make use of gems and other Ruby on Rails functionality themselves, the user must be able to use compilers.

[4u123]

For users to make use of gems and other Ruby on Rails functionality themselves, the compilers tweak must be disabled.

Evidently.

I dont see any circumstance where I would allow users general access to the compilers in a shared hosting environment. I certainly would not open up the security of my servers just so a handful of customers could install ruby modules. The idea is laughable.

Because of this, its a poor implementation and you have rendered it basically useless. There is no way we can offer this functionality to our customers when it requires them to have access to gcc.

You guys really need to find a way to make this work without public access to the compilers because its simply not worth taking the risk.

[manokiss]

For users to make use of gems and other Ruby on Rails functionality themselves, the compilers tweak must be disabled.

David....do you mean enabled?

[4u123]

David....do you mean enabled?

No he means disabled.

Tweak enabled = no access to compilers.

Tweak disabled = access to compilers.

Its actually the same for Perl modules. With the tweak enabled, customers cant install Perl modules either. I'm sure the process could easily be safely passed on to another script though. There must be a way around this.

[cPanelDavidG]

David....do you mean enabled?

Whoops, yes, I did mean enabled. Edited post.

[4u123]

Whoops, yes, I did mean enabled. Edited post.

No - you meant disabled.

[manokiss]

David, there are any workaround for this?.....im not a Ruby expert....how often a ruby user need install gems? I guess we could install the gems server wide and will be accessible to the users?

Thank you!

[cPanelDavidG]

No - you meant disabled.

Ack, been a busy week.

Long story short: user must be able to use compilers if you want to let them install gems.

[4u123]

lol yes, you got it right the first time. Your reply was for me and I knew what you meant so it doesnt really matter either way.

[jpetersen]

I dont see any circumstance where I would allow users general access to the compilers in a shared hosting environment. I certainly would not open up the security of my servers just so a handful of customers could install ruby modules. The idea is laughable.

Disallowing compilers doesn't increase your security - it's just a temporary inconvenience sometimes. If someone can't use gcc on your box, then they can grab a precompiled binary from somewhere else, or they can use interpreted code instead to achieve whatever they're after.

[4u123]

Disallowing compilers doesn't increase your security - it's just a temporary inconvenience sometimes. If someone can't use gcc on your box, then they can grab a precompiled binary from somewhere else, or they can use interpreted code instead to achieve whatever they're after.

Disabling the compilers does, without any doubt, increase your security.

A large part of server security in a hosting environment is about making it difficult for hackers to do what they want. Just like disallowing access to other binaries like wget, disabling the compilers is a general deterrent, it also shows hackers that you are security concious and makes them more likely to move on to target servers elswhere that may not be as well secured.

Most of the exploits that get distributed around are written to use the system compilers and they rarely come with a pre-compiled binary or a seperate compiler. I agree that if a hacker manages to get into a users account they can pretty much do what they like if they know what they are doing - but that is no reason to make it easy for them! In a lot of cases these days, the "hacker" is someone who got hold of a script and they dont have enough knowledge to do anything else if it doesnt work on the first attempt.

Its not one answer to the problem but as part of a solid securty policy it helps to deter and delay. Disabling the compilers is also a good idea to prevent some trojans and worms from doing damage should they get into the system. Its very well documented that for good security in this kind of environment, in addition to other changes, the compilers should be disabled. In my opinion, as I mentioned earlier, enabling them just so the customer can install some ruby components would be very stupid.

[4u123]

David, there are any workaround for this?.....im not a Ruby expert....how often a ruby user need install gems? I guess we could install the gems server wide and will be accessible to the users?

Thank you!

Because this doesnt come with many gems already installed, customers are more likely to want to install their own. Unlike Perl where there are a great number of installed modules. Its very rare for a customer to request a new perl module. In the last 5 years I'd say we've had only a handful of requests for Perl modules that arent already installed.

If I knew a little more about Ruby I'd feel confident to install the most commonly used gems - then, as with Perl, we wouldnt get hassled about it.

(I've still got this under close scrutiny anyway - I noticed a rails process getting stuck and using 100% CPU only a day after enabling it.)

The alternative in both these cases would be to somehow pass on the installation to a different process that is not owned by the cpanel user. I dont know how complicated that would be though.