1

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?
  • 1
    You probably don't need any compilers on a web server, so should be safe to remove them all. However, there are exceptions to this - mostly around specialist needs, such as running compile services as part of a website. We don't know if you have any of these uncommon requirements, though. – Matthew Aug 3 '16 at 11:21
  • @Matthew: I use apt-get for updates, and everything seems to come in binaries. I'll try removing CC and friends. Should I remove Python, Ruby and other script interpreters unless my own services use them? – forthrin Aug 3 '16 at 11:50
  • @forthrin That depends on what else you have installed on your webserver. Python in particular tends to show up in unexpected places. – Philipp Aug 3 '16 at 14:50
  • Related: security.stackexchange.com/q/24444/165253 – forest Sep 14 at 3:07
4

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...

  • Thanks for taking the time to give good and also more broad advice. Can you elaborate on point 3 ("Server running as root")? By server, do you mean Unix itself or specifically the Web server (such as nginx/PHP)? How, specifically, does one not run a server as root? – forthrin Aug 3 '16 at 13:05
  • @forthrin: many server softwares, Tomcat, Apache, ftp or mail servers and so on can be configured to: 1. start as root as they are normally started as system daemons 2. do their initialization part as root (open reserved port sockets...) 3. switch to an unprivileged user to process requests. Sometimes you have a master running as root that forks childs to processing requests. In that case, the child switch to the unpriviledged user before processing request. That way, if a bug allows a malicious request to break the server, only unpriviledged access will be obtained – Serge Ballesta Aug 3 '16 at 13:17
  • /etc/init.d/php-fastcgi says USER=www-data and /etc/nginx/nginx.conf says user www-data. So that's good, right? How do I secure Postfix and MySQL? (Currently they are both started using sudo service ... start). Is sudo -u mysql an option? (In that case, I would have to give the mysql user a password, which it does not have at the moment.) – forthrin Aug 3 '16 at 13:36
  • @forthrin: a database server should never run as root. On my FreeBSD system the postgresql server starting script contains su -l ${postgresql_user} -c "exec ${command} ...}". When this is run as root, no password is asked but the command is executed as ${postgresql_user}. – Serge Ballesta Aug 3 '16 at 14:00
1

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?

0

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.

0

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.

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