During the setup of my virtual server instances I require some applications to be built using make. Are there any security risks associated with having make installed? Or should I clean it up before the instance is deployed?

I also have the gcc compiler on the server which I use to build applications before deployment.

  • 4
    If it makes you feel any better, any piece of software installed anywhere creates a vulnerability.
    – MDMoore313
    May 16, 2014 at 18:09
  • 1
    And one with non-root shell access to a server could download a "distro independent" compiler package(.tar.gz) that will not need to be installed so...
    – user122772
    May 16, 2014 at 20:32
  • 1
    Is it me, or is the combination of "is it safe?" and "root access" rather uncomfortable?
    – DNA
    May 16, 2014 at 22:18
  • 2
    If you already have gcc installed, there's practically no way that make could make any potential security problem worse.
    – Shadur
    May 17, 2014 at 10:51
  • 1
    @Shadur What difference does having GCC make? If the user already has access to the machine they can upload any copy of gcc trivially. Anyway, gcc can be useful to unprivileged users and not a security risk as long as no privileged users run it.
    – Vality
    May 17, 2014 at 22:21

6 Answers 6


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.

  • 7
    I would add to this that a number of production system rely on interpreted code (e.g. PHP, Perl, Python, ...). Banning development tools in this context wouldn't make sense. I'd consider compilers like gcc not to present a higher risk than these. As you say, an attacker in a position to use the compilers installed on a system would generally by in a position to do worse things anyway, such as uploading their own (possibly statically linked) executable.
    – Bruno
    May 15, 2014 at 21:24
  • 3
    Relevant: A tiny version of wget (51 bytes?). A real life example of an attacker moving a binary to the server using subsequent echo statements into a file. The whole process is automated with a script found in the same link.
    – Adi
    May 16, 2014 at 13:41
  • 2
    @Adnan, interesting. As far as I can tell, the main security flaw in this DVR example is the fact that the attacker can telnet to it as root with password 123456 in the first place. Having or not having wget or other tools (before the attack) is then barely relevant indeed.
    – Bruno
    May 16, 2014 at 14:57

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.

  • 2
    An answer so zen I don't know how to rate it.
    – kasperd
    May 16, 2014 at 17:27
  • 5
    @kasperd This answer is intended to be serious. I thought that bringing a programmer's point of view could be helpful. A function that translates an input into an output does not introduce a vulnerability just because its output is in a CPU-understandable format.
    – ignis
    May 16, 2014 at 18:28
  • 2
    I agree with the point you are making. I think your answer is a great read to anybody who already agree with it. I am just worried that your answer may come across as a joke to somebody who disagree with it.
    – kasperd
    May 16, 2014 at 19:28
  • 1
    I like this answer much more than the accepted one :)
    – Ruslan
    May 18, 2014 at 8:36

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.

  • 8
    I'm asking out of curiosity and ignorance here: Why do you say that the presence of compilers are a "significant security issue?" What's the security issue with having a compiler installed? Is it just a matter of you shouldn't be building your code on a production server in the first place and thus the compiler is superfluous, or is there actually a significant security issue with the presence of the compiler itself?
    – reirab
    May 15, 2014 at 20:24
  • 12
    While it's a good idea to build your applications on a separate server, saying the presence of compilers on a production system is a significant security issue doesn't make sense. What about scripting languages and JIT-compiled systems (Perl, Python, Java, ...)?
    – Bruno
    May 15, 2014 at 21:25
  • 4
    The presence of of compilers on a production environment is not a "significant security risk". I, myself, have moved binaries to compromised boxes using echo and base64. In fact, you can even do it with a series of echo statements and no other tool.
    – Adi
    May 16, 2014 at 15:11
  • 1
    Good points, all. I've edited my answer to clarify.
    – EEAA
    May 16, 2014 at 21:42

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.


You’re asking if make should be installed on a production server, but my real question would be: Who has access to that production server & what safeguards do you have in place to deal with an incursion? If make was not installed but someone gain root access, guess what? They can manually install make and anything they want.

The harsh reality about computer security is as much as you want to prevent unwanted access, being obsessed with blocking access is not as important as:

  1. Who has access to the server?
  2. What can you do to rollback from the aftermath of a break in?

This is all dependent on what kind of work you do. I work primarily in the web server world & my attitude is basically, anyone getting production server access from me needs to prove skills, knowledge & maturity. That’s it. Sometimes it takes a few days. Sometimes it takes months. But basically, your best line of security on production servers is controlling access on top of the sundry other things we do to harden servers.


make itself is harmless. All it does is run applications in a set order, depending on dependencies you specify and what files already exist in the system. It can even be useful as part of the install process: you can use it to put prebuilt files where they need to go, or run unit tests, or other things.

However, you do need to consider what exactly you want to use it for. It is often used in conjunction with compilers and other tools for building applications, and those could be used to negate some of your lines of defense. But make can't do these things if the tools aren't available.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.