How do I harden compilers (as suggested by Lynis)?

Question

This article suggests to restrict compilers to root, but does not say how, and I couldn't find anything useful by searching the Web.

ii  g++                                4:5.3.1-1ubuntu1                    i386         GNU C++ compiler
ii  g++-5                              5.4.0-6ubuntu1~16.04.1              i386         GNU C++ compiler
ii  gcc                                4:5.3.1-1ubuntu1                    i386         GNU C compiler
ii  gcc-4.7                            4.7.4-3ubuntu12                     i386         GNU C compiler
ii  gcc-4.7-base:i386                  4.7.4-3ubuntu12                     i386         GCC, the GNU Compiler Collection (base package)
ii  gcc-4.8                            4.8.5-4ubuntu2                      i386         GNU C compiler
ii  gcc-4.8-base:i386                  4.8.5-4ubuntu2                      i386         GCC, the GNU Compiler Collection (base package)
ii  gcc-5                              5.4.0-6ubuntu1~16.04.1              i386         GNU C compiler
ii  gcc-5-base:i386                    5.4.0-6ubuntu1~16.04.1              i386         GCC, the GNU Compiler Collection (base package)
ii  gcc-6-base:i386                    6.0.1-0ubuntu1                      i386         GCC, the GNU Compiler Collection (base package)

1. Which of these compilers can I remove (on a Ubuntu Web server)?
2. Should I remove interpreters like Python and Ruby too?
3. Which Bash commands can I use to harden required compilers?

Answer 1

Security is always a balance between ease of use and protection. The most secure system I can imagine is a switched off computer lying in a bank safe. Unfortunately it is also hard to use... Removing compilers or worse restricting them to root on a test or dev system would be nonsense: either you can no longer use it, or you will always log in as root. Things go differently on a production only server where they can normally be removed.

But I can hardly imagine how removing a compiler could secure an Ubuntu server. As for any Debian-like systems, packages are generally installed in binary form, meaning that if an attacker has write access to a folder, he can deposit a program built on his own machine and use it there. And if he has no write access, it will not be able to build an executable file either.

This advice, as many other on security by obfuscation looks like snake oil. That should not cause many harm, but won't really secure anything either... But it is something that is easy to implement in a automatic auditing tools, and can be sold

If you really want to secure a production server, don't focus on compilers, but carefully remove all network (and generic) tools that are not used there, and configure the firewalls to block as many incoming and outgoing connections as possible: if one server was compromised, it will really be harder for the attacker to bounce onto another one. But this cannot be done by an automatic tool because it must be adapted to the actual environment and precise use case of the server. Once this is done, it is possible that the compilers will already have gone away but honestly I would not care. If you want to go one step further, also build a custom kernel containing only drivers used in your environment - ok, you cannot build a kernel if you have removed compilers, but it should be built and tested on the dev or pre-prod system. That way script kiddies trying to use usual kernel addresses won't be able to find them.

TL/DR: my advice is that you do not know what compiler can safely be removed or how you could restrict them to root, do not even try to do it. Just follow the common best practices:

• never use root account for anything that does not require it
• only sudo individual commands or for a short time
• never let a server running as root (except for its initialization time...) and ensure that it leaves all unnecessary privileges before accepting requests
• secure your firewall the best you can and forbid all unnecessary accesses
• do not install unnecessary or non controlled software

And do not trust automatic auditing tools for more than they can do. A serious security audit really costs time and money...

Answer 2

From a hacker/pentester perspective, I can say that having a compiler on a target machine and/or python/ruby can be very very useful. So I agree with one of the previous answers that removing it from a production server increases security. However, those tools are only useful for attackers who already have a limited shell on your system. In that case, you can make their live harder by not giving them additional useful tools which they need for privilege escalation. But this is not a huge gain in security. You would want to prevent them from getting a shell in the first place and that has nothing to do with a compiler or interpreter tool. On the other hand, removing gcc and python/ruby on a production server is probably not a huge issue, either, so why not doing it. As previously said, I don't see why a production server needs a compiler. If it needs python/ruby depends on the software run on that box. If no software depends on python/ruby then you can uninstall it without concern. Allowing gcc only for root would also help prevent someone from using it for privilege escalation. But I would question what's the benefit compared to removing it, or in other words: which root user needs it?

Answer 3

Nobody is given you answer specific to lynis. From your question, you need to know how to do this because lynis suggests that you harden the compiler binary for root access only. So here how I did it to suppress lynis warning:

sudo chmod o-rx /usr/bin/gcc
sudo chmod o-rx /usr/bin/g++

Use this if you have no choice to keep the compilers in your system. Everyone here is suggesting that you remove the compiler but sometimes you do need this to compile things without the need to reinstall manually. Maybe cronjob need this compiler to work in the background to compile new PHP release.

Having compilers inside web server is bad but in some situations it's not an easy task to just remove a compiler from your system. If you have specific perl-module that depends on the compiler to work, then you cannot just remove the compiler. For example, when I try to remove g++ by running this command from my system:

yum remove g++

I got the following error message:

Problem: conflicting requests
  - nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64

This is because the perl module is depending heavily in g++ compiler. So, use the above method if you don't want to mess with this perl-module.

But let's say you do not have any dependencies to use compiler, you remove this:

yum remove g++
yum remove gcc

This will remove all the compiler dependencies that listed in your post.

Answer 4

You should be able to safely remove the C and C++ compilers. Doing so is relatively simple and normally painless. It's likely a relatively small gain in security, but for a production server environment it's unlikely to need a C or C++ compiler. I'd likely question why someone needs to build production code on a production server. The security gains likely aren't terribly high, but the costs are also generally very low.

Removing interpreters like Python or Ruby is potentially a little more costly, since administration tools are often written in these languages, which may cost you some utility and flexibility. Your particular use case should be taken into account.

Just keep in mind that removing different compilers and interpreters presents a spectrum of utility vs security. Removing the bash interpreter, for instance, would make the system difficult, or impossible to manage since bash scripts are used everywhere to start/stop services and maintain the software.

Answer 5

Security is the fine art of doing the right things, even if they in itself don't always look to be having a big impact. The biggest reason for removing or restricting the usage of compilers on production systems is already given by kaidentity. The article about privilege escalation (in the referred link), gives some idea how it works, and how you can defend by removing the compiler, or restricting its usage.