Is it safe for a production server to have make installed?

Solution 1:

Some people will argue that the presence of development tools on a production machine will make life easier for an attacker. This however is such a tiny roadbump to an attacker, that any other argument you can find for or against installing the development tools will weigh more.

If an attacker was able to penetrate the system so far, that they could invoke whatever tools are present on the server, then you already have a serious security breach. Without development tools there are many other ways to write binary data to a file and then run a chmod on that file. An attacker wanting to use a custom build executable on the system at this point could just as well build that on their own machine and transfer it to the server.

There are other much more relevant things to look out for. If an installed piece of software contains a security bug, there is a few ways it could be exposed to an attacker:

• The package could contain a suid or sgid executable.
• The package could be starting services on the system.
• The package could install scripts that are invoked automatically under certain circumstances (this includes cron jobs, but scripts could be invoked by other events for example when the state of a network interface changes or when a user logs in).
• The package could install device inodes.

I would not expect development tools to match one of the above, and as such is not a high risk package.

If you have workflows in which you would make use of the development tools, then you first have to decide whether those are reasonable workflows, and if they are, you should install the development tools.

If you find that you don't really need those tools on the server, you should refrain from installing them for multiple reasons:

• Saves disk space, both on the server and on backups.
• Less installed software makes it easier to track what your dependencies are.
• If you don't need the package, there is no point in taking the additional security risk from having it installed, even if that security risk is tiny.

If you decide that for security reasons, you won't allow unprivileged users to put their own executabels on the server, then what you should avoid is not the development tools but rather directories writable to those users on file systems mounted with execute permissions. There may still be a use for development tools even under those circumstances, but it is not very likely.

Solution 2:

make is a shell that has a different syntax than bash.

A compiler like gcc is a powerful awk configured with a set of substitutions that standard awk does not support. It is a non-POSIX-compliant sort or cat that injects rubbish in the output. It is an interactive text editor (think vi) which is configured to do some editing on startup, then exit before displaying the user interface.

There is nothing inherently insecure in them, they do not make your machine more insecure than one where you have bash + cat + shell redirection.

Solution 3:

make itself is fine. make is merely a dependency tracking and automation framework. It is typically used in conjunction with compilers, though, and those preferrably should not be available on a production system, as they're completely un-necessary. The same holds true for all un-needed packages, whether those be shared libraries, interpreters, etc. Software installed on production systems should be strictly controlled, and only those packages that are required by the application should be present.

You should be building your application on a build server, packaging it, and then deploying the binary package to your production systems.

Note: native packaging tools suck. Don't even bother trying to grok them. Instead, check out Jordan Sissel's fpm. It makes packaging an absolute joy.

Solution 4:

On the contrary, the potential issue isn't with having make on the production server, the potential issue is with building the applications on the production server instead of deploying tested pre-built images. There may be valid reasons for this methodology, but it's one I would argue against strenuously were I asked to adopt it.