I actually did it live on prod boxes in last job and then used the in-place binary upgrade signal to seamlessly restart nginx. A dev who'd never touched prod and I wrote an ansible playbook for it.
This is something I noticed at my previous job (removing user access to gcc, make, ld etc so only root can run it[1]) and never understood.
It reminds me of blocking ping to improve security or worse blocking all ICMP.
Compiler, and especially make are harmless by themselves. They aren't setuid all it's used for is translate file from one format (source code) to another (machine code). One might as well block sed, because it could be used to modify /etc/passwd or /etc/shadow.
A someone who would want to compromise hosts if they need binaries, they would precompile them statically, that way is a single file, no need for libraries and no need extra development packages with header files and more likely to work across wide range of systems.
[1] because, there were chef recipes that were compiling things :> Also, it decreases security, because now you need to run compiler as root, so you could be compromised through things like this: http://securitytracker.com/id/1004374
Imagine an attacker is able to inject small files onto the system via a channel that would not let them transmit arbitrary binary data, and that the system is otherwise sufficiently firewalled to prevent them from just downloading their own tools without first further compromising the system. Having a compiler available can make it substantially easier to bootstrap a toolchain to compromise the system fully.
Another issue is that it presents a privilege escalation concern. If you compile stuff in a user account on the production machines that will be run with root privileges, if someone compromises that user account they can now put in place a compiler wrapper to embed their own code. Even if you don't do anything else in that account (e.g. sudo) that'd let them e.g. capture passwords the compilation presents another risk. (As an extension to this: Your dev and build environments are security critical; but in your production environment is often far more vulnerable - not least because it's far more visible)
I don't think these are very high on the list of things you should worry about as your system needs to be very locked down before an attacker that is able to make use of them won't have other just as good opportunities, but the more stuff you run in your production environment, the more opportunities you give an attacker.
>Imagine an attacker is able to inject small files onto the system via a channel that would not let them transmit arbitrary binary data, and that the system is otherwise sufficiently firewalled to prevent them from just downloading their own tools without first further compromising the system.
I'd just send the binaries base64 encoded. Decoding is trivial, with any number of tools commonly installed in the system.
Limiting access to compilers, alone, is 100% useless. You either go a lot farther down that road, or there is no point in starting.
You can compile local exploits instead of having to download them. If the machine is fully stripped enough it can be a good thing. Most of the time it's just an annoyance.
Eg. Windows boxes rarely have a compiler and get hacked all the time.
My view is that if people on my box can run a compiler, they surely can run Ruby, or Python, or PHP or one of the many many other dynamic languages that I have which will let them do whatever it is they want.
